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FOREWORD

This Indian Standard which is identical with ISO/IEC 9066-2 : 1989 `Information processing 2 : Protocol specification', issued by the systems -Text communication - Reliable transfer-Part International Organization for Standardization ( IS0 ) was adopted by the Bureau of Indian Standards on the recommendation of Computer Systems and Interconnection Sectional Committee ( LTD 36 ) and approval of the Electronics and Telecommunication Division Council. In the adopted standard certain terminology and conventions are however not identical used in Indian Standards. Attention is particularly drawn to the following: Wherever the words *International be read as -Indian Standard'. In this Indian Standard, the following respective place the following:
International Standard IS0 7498 : 1984 Information

to those

Standard'

appear

referring

to this standard, are referred to.

they should Read in their

International

Standards

Indian Standard

processing systems - Open systems interconnec,tion - Basic reference model IS0 8649 : 1988 Information processing systems - Open systems interconnecdefinition for the tion - Service association control service element IS0 8650 : 1988 Information processing systems - Open systems interconnection - Protocol specification for the association control service element IS0 8822 : 1988 Information processing systems - Open systems interconnection - Connection oriented presentation service definition Information ISO/IEC 9066-I : 1989 processing systems - Text communication - Reliable transfer - Part 1 : Model and service definition Information ISO/IEC 9072-I : 1989 processing systems - Text communication - Remote operations - Part 1 : Model, notation and service definition

IS 12373 ( Part 1) : 1987 Basic reference model of open systems interconnection for information processing systems : Part I ( Identical ) IS 13615 : 1992 Service definition for the association control service element in open systems interconnection for information processing systems ( Identical ) IS 13706 : 1993 Protocol specification for the association control service element in open systems interconnection for information processing systems ( Identical ) Dot LTD36 ( 1636 ) Pl Connection oriented presentation service definition in open systems interconnection for information processing systems ( under draft standard formulated ) ( Identical ) IS 13707 ( Part 1 ) : 1993 Reliable transfer in text communication for information processing systems : Part 1 Model and service definition ( Identical ) IS 13675 ( Part 1 ) : 1993 Remote operations in text communication for information processing systems : Part I Model, notation and service definition ( Identical ) of this standard has reviewed the that they are acceptable for use in interconnection interconnection interconnection ASN. I ) Service SpecifiSpec& it

The technical committee responsible for the preparation provisions of the following IS0 Standards and has decided conjunction with this standard:

ISO/TR 8509 : 1987 Information processing systems - Open systems conventions IS0 8824 : 1987 Information processing systems - Open systems cation of abstract syntax notation one ( ASN. I ) IS0 8825 : 1987 Information processing systems - Open systems cation of basic encoding rules for abstract syntax notation one ( Only the English language text in the International in this standard.

Standard has been retained

while adopting
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Indian Standard
RELIABLE TRANSFER IN TEXT COMMUNICATION FOR INFORMATION PROCESSING SYSTEMS
PART 2 PROTOCOL SPECIFICATION .

1

Scope

This part of ISO/IIX 9066 specifies the .protocol (abstract syntax) and procedures for the Reliable Transfer Service Element services (ISO/IEC 90661). The RTSE services are provided in conjunction with the Association Control Service Element (ACSE) services (IS0 8649) and the ACSE protocol (IS0 8650), and the presentation-service (IS0 8822). The RTSE procedures a) are defined in terms of RTSE use of

IS0 8649: 1988, Information processing systems Open Systems Interconnection - Service definition ' for the Association Control Service Element. IS0 8650: 1988, Znformation processing systems Open Systems Interconnection - Protocol specification for the Association Control Service Element. IS0 8822: 1988, Information processing systems Open Systems Interconnection - Connection oriented presentation service definition. -

the interactions between peer protocol machines through the ACSE and the presentation-service; the interactions protocol machine

IS0 8884: 1987, Information processing systems Open Systems Znterconnection - Specification of Abstract Syntax Notation One (ASN.1). IS0 8825: 1987, Information processing systems Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1). ISOIIEC 9066-l: 1989, Information processing systems - Text communication - Reliable Transfer - Part 1: Model and service definition. ISOiIEC 9072-t: 1989, Znformation processing Communication - Remote systems - Text Operations - Part 1: Model, notation and service definition.

b)

between the RTSE and its service-user. specifies conformance implementing these

This part of ISO/IEC 9066 requirements for systems procedures.

2

Normative references

The following standards contain provisions which, through refe'rence in this text, constitute provisions of this part of ISO!IEC 9066. At the time of publication, the editions were valid. All Standards are subject to revision, and parties to agreement based on this part of ISO/IEC 9066 are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IS0 and IEC maintain Registers of currently valid International Standards. IS0 7498: 1984, Information processing systems Open Systems Interconnection - Basic Reference Model. ISO/TR 8509: 1987, Information processing systems - Open Systems Interconnection - Service Conventions.

3
3.1

Definitions
Reference model definitions

This part of ISO/IEC 9066 is based on the concepts developed in IS0 7498 and makes use of the following terms defined in it: a) b) c) d) Application Layer;

application-process; applic`ation-entity; application-service-element;
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e)

application-protocol-data-unit; application-protocol-control-information; presentation-service; presentation-connection; session-service; session-connection; user-element; two-way-alternate transfer syntax. Service conventions definitions interaction; and

3.5

RTSE service

definitions

0

g)
h) i) j) k) 1) m) 3.2

This part of ISO/IEC 9066 makes use of the following terms defined in ISO/IEC.9066-1: a) b) c) d) e) f) g) h) i) j) k) 1) association-initiating-application-entity; association-initiator; association-responding-application-entity; association-responder; sending-application-entity; receiving-application-entity; requestor; acceptor; Reliable Transfer Service Element; RTSE-user; RTSE-provider; ACSE-provider; monologue interaction; sender; receiver;

This part of ISO/IEC 9066 makes use of the following terms defined in ISO/TR 8509: a) b) c) d) e) f) g) h) i) j) 3.3 service-provider; service-user; confirmed service; service; service;

non-confirmed

syntax-matching-services;

provider-initiated primitive; request (primitive); indication

m) Reliable Transfer; n) 0) 3.6 X.410-1984 mode; and

normal mode. Reliable specification Transfer definitions protocol `the

(primitive); and

response (primitive); confirm (primitive). Presentation service

For the purpose of this part of ISO/IEC 9066 following definitions apply: definitions use of the

This p,art of ISO/IEC 9066 makes following terms defined in IS0 8822: a) b) C) d) 3.4 abstract syntax; abstract syntax name; presentation context; and

3.6.1' reliable-transfer-protocol-machine: The protocol machine for the Reliable Transfer Service Element specified in this part of ISO/IEC 9066. 3.6.2 requesting-reliable-transfer-protocolmachine: The reliable-transfer-protocol-machine whose RTSE-user is the ,requestor of a particular Reliable Transfer Service Element service. 3.6.3 accepting-reliable-transfer-protocolmachine: The reliable-transfer-protocol-machine whose RTSE-user is the acceptor for a particular Reliable Transfer Service Element service. 3.6.4 sending-reliable-transfer-protocolmachine: The reliable-transfer-protocol-machine whose RTSE-user is the sender.

default context. Association control definitions use of the

This part of ISO/IEC 9066 makes following terms defined in IS0 8649: a) b) c) d) application-association; application Association X.410-1984 context;

association;

Control Service Element; and mode.

2
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3.6.5 receiving-reliable-transfer-protocolmachine: The reliable-transfer-protocol-machine
whose RTSE-user is the receiver.

5

Conventions

3.6.6 association-initiating-rellabletransfer-protocol-machine: The reliabletransfer-protocol-machine whose RTSE-user is the association-initiator. 3.6.7 association-responding-reliabletransfer-protocol-machine: The reliabletransfer-protocol-machine whose RTSE-user is the association-responder.

This part of ISO/IEC 9066 employs a tabular presentation of its APDU fields. In clause 7, tables are presented for each RTSE APDU. Each field is summarized using the following notation: M U T req ind resp conf sP presence is mandatory presence is a RTSE service-user presence is a RTPM option source is related request primitive sink is related indication primitive option

4
4.1
APDU 4.2

Abbreviations
Data, units
application-protocol-data-unit

source is related response primitive sink is related confirm primitive

source or sink is the RTPM

Types
UdkS

of application-protocol-data-

The structure of each RTSE APDU is specified in clause 9 using the abstract syntax notation of IS0 8824.

The following abbreviations have been given to the application-protocol-data-units defined in this part of ISO/IEC 9066. RTAB RTORQ RTOAC RTORJ RTTR RTTP RT-P-ABORT and RT-U-ABORT application-protocol-data-unit RT-OPEX-REQUEST protocol-data-unit RT-OPEN-ACCEPT protocol-data-unit RT-OPEN-REJECT protocol-data-unit RT-TRANSFER data-unit applicationapplication-

6
6.1

Overview

of the protocol

Service provision

The protocol specified in this part .of ISO/IEC 9066 provides the services defined in ISO/IEC 9066-l. These services are listed in table 1

Table 1 - RTSE service summary

application-

Service
application-protocolapplicationRT-OPEN RT-CLOSE RT-TRANSFER RT-TURN-PLEASE RT-TURX-GIVE RT-P-ABORT RT-U-ABORT

Type
Confirmed Confirmed Confirmed Non-confirmed Non-confirmed Provider-initiated Non-confirmed

RT-TOKEN-PLEASE protocol-data-unit Other abbreviations

4.3

The following abbreviations of ISO/IEC 9066.

are used in this part

AE
ACSE

application-entity
Association

6.2 6.2.1

Use of services ACSE services

Control Service Element

ASE RTPM

application-service-element reliable-transfer-protocol-machine

RT (or RTS) Reliable Transfer RTSE Reliable Transfer Service Element

The RTPNi requires access to the A-ASSOCIATE, A-RELEASE, A-ABORT and A-P-ABORT services. This part of ISO/IEC 9066 assumes that the RTPM is the sole user of these services.

3
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6.2.2

Use of the Presentation-service

The RTPM requires access to the P-ACTIVITYSTART, P-DATA, P-MINOR-SYNCHRONIZE, PACTIVITY-END, P-ACTIVITY-INTERRUPT, PACTIVITY-DISCARD, P-U-EXCEPTIONREPORT, P-ACTIVITY-RESUME, P-PEXCEP'l?ON-REPORT, P-TOKEN-PLEASE and P-CONTROL-GIVE services. This part of ISO/IEC 9066 assumes that the RTPM is the sole user of the above services. The RTPM requires access to local syntaxmatching-services provided by the presentationservice provider. This syntax-matching-service consists of a) An encoding service enabling the transformation from the local representation of an APDU value into an encoded-APDU-value of type OCTET STRING the value of which is the representation of the APDL value specified by the negotiated transfer syntax. A decoding service enabling the transformation from an encoded-APDUvalue into the local representation of the APDU value..

use a single presentation context or multiple presentation c&texts as a part of the presentation multiple defined context facility. The choice is determined by the use of the single presentation context parameter of the RT-OPEN service as describedin8.1..1.1.3and8.1.1.1.4. 6.3 Model

The reliable-transfer-protocol-machine (RTPM) communicates with its service-user by means of primitives defined in ISO/IEC 9066-l. Each invocation of the RTPM controls a single application-association. The RTPM is driven by RTSE service request and response primitives from its service-user, and by indication and confirm primitives from the ACSE services and the presentation-service. The RTPM, in turn, issues indication and confirm primitives to its service-user and request and response primitives on the used ACSE services or presentation-service. The reception of an RTSE service primitive, or of an ACSE service primitive, or of a presentationservice primitive, and the generation of dependent actions are considered to be indivisible. During the use of the RTSE services, the existence of both the association-initiating AE and the association-responding AE is presumed. How these AEs are created is beyond the scope of this part of ISO/IEC 9066 During th;e use of the RTSE services, except RT-OPEN, the existence of an applicationassociation between the peer AEs is presumed.
NOTE Each application-as+ociation end system by an internal, may be identified implementation in an

b)

If X.410-1984 mode or simple e&ding is used by the Presentation Layer, the APDU value is encoded as ASN.l type ANY. If full encoding is used by the Presentation Layer, the APDU value is encoded as ASN.l type EXTERNAL. (For X.410-1984 mode, single encoding and full encoding see IS0 8823). This part of ISO/IEC 9066 recognizes that the ACSE services require access to the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services. This part of ISO/IEC 9066 assumes that the ACSE and the RTPM are the sole users of any of the above, or of other, any presentation-services. During the lifetime of an applicat'ion-association, the underlying presentation-connections either

dep'endent

mechanism

so that the RTSE service-user, can

and the RTPM, and the ACSE service-provider refer to it.

4
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7

Elements

af procedure
consists of the following

The RTSE protocol elements of procedure: a)

The association-establishment procedure uses the RT-OPEN-REQUEST (RTORQ) APDU, the RT-OPEN-ACCEPT (RTOAC) APDU, and the RT-OPEN-REJECT (RTORJ) APDU.
NOTE These APDUs are also used in the association-

association-establishment

b) association-release c) transfer 4
e) turn-please turn-give fI1 user-exception-report f2) provider-exception-report
7.1.2.1

recovery procedure.

RTORQ

APDU

f-l e-ror reporting:

The RT-OPEN-REQUEST .(RTORQ) APDU is used in the request to ,establish an applicationassociation. The fields of the RTORQ APDU are listed in table 2.
7.112.2 RTOAC APDU

Ed error
gl) 82) g3) g4) hl transfer-interrupt transfer-discard association-abort association-provider-abort

The RT-OPEN-ACCEPT (RTOAC) APDU is used in the positive response to the request to establish an application-association.The fields of the RTOAC APDU are listed in table 3. 7.1.2.3 RTORJ APDU

error recovery: hll transfer-resumption (for recovery from gl, or after successful h3 from g3 or g41 h2) transfer-retry (for recovery from g21 h3) association-recovery (for recovery from g3 or g41 abort ill transfer-abort or g3 or g4 not i2). provider-abort or g3 or g4 not i31 user-abort. (recovery possible1 (recovery possible) from gl or g2 from gl or g2

The RT-OPES-REJECT (RTORJ) APDC is used in the negative response to the request to establish an application-associationThe fields of the RTORJ APDU are listed in table 4.
7.1.3
a)

il

Association-establishment

Procedure

This procedure

is driven by the following events: from the

an RT-OPEN request primitive requestor (association-initiator);

b) cl dl

an RTORQ APDU as user-data on an AASSOCIATE indication primitive an RT-OPEN response primitive acceptor (association-responder); from the

In the following subclauses, a summary of each of these elements of procedure is presented. This consists of a summary of the.relevant APDUs, and a high-level overview of the relationship between the RTSE service primitives and the APDUs involved and the used presentation-service. Clause 8 describes mapped on the presentation-service. 7.1
7.1.1

an A-ASSOCIATE confirm primitive that may contain either an RTOAC APDU, or an RTORJ APDU, or no APDU.
RT-OPEN request primitive

how the service primitives are ACSE services, and on the

7.1.3.1

Association-establishment Purpose

The association-establishment procedure to establish an application-association.
7.1.2 APDUs used

is used

The requesting RTPM forms an RTORQ APDU from the parameter values of the RT-OPEN request primitive and its internal data. The RT-OPEN request primitive parameters, except user-data, are stored by the requesting RTPM for association-re'covery. The requesting RTPM issuks an A-ASSOCIATE request primitive also using information from, the RT-OPEN request primitive. The RTORQ APDU is the user information parameter value of the A-ASSOCIATE request primitive.

5
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Table 2 - RTORQ APDC fields

I

I

Field name Checkpoint-size Window-size Dialogue-mode User-data Session-connection-identifier. Application-protocol

I

Presence T T U .U T U

I

Source
SP SP req reel SP rect

Sink sP sP ind ind SP. ind

1) 2) 3)

NOTES

1 2 3

The user-data field is used solely in the association-establishment The session-connection-identifier

procedure procedure

field is used solely in the association-recovery

The application-protocol field is usedsololy in the X.410-1984 mode.

Table 3

- RTOAC APDU fields

Field name Checkpoint-size Window-size User-data Session-connection-identifier

Presence T T U T

Source
SP

Sink
SP

1) 2)

resp
SP

SP

conf
SP

SP

NOTES

I 2

The user-data field is used solely in the association-establishment The session-connection-identifier

procadure procedure.

field is used solely in the association-recovery

Table 4

- RTORJ APDL' fields

I

Field name Refuse-reason User-data 11 2)

Presence T U

Source sP resp

Sink sP conf

NOTES

1
2

The refuse-reason field is used solely in the X.410-1984 mode The user-data field is used solely in the normal mode, and is not used in the associationrecovery procedure.

The requesting RTPM waits for a primitive from the ACSE-provider and does not accept any other primitive from the requestor. 7.1.3.2 RTOtiQ APDU

If the application-association is not accepted by the ACSE-provider, no A-ASSOCIATE indication primitive is received by the accepting RTPM and no action takes place.

6
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If the application-association is accepted by the ACSE-provider, the accepting RTPM receives the RTORQ APDU as the user information parameter on an A-ASSOCIATE indication primitive. If any of the A-ASSOCIATE indication parameters or any of the RTORQ APDU fields is unacieptable to the accepting RTPM, or if the accepting RTPM is not able to accept the application-association, it forms and sends an RTORJ APDU with appropriate parameters from internal data. The accepting RTPM issues an AASSOCIATE. response primitive. The RTORJ APDU is sent as the user information parameter of the A-ASSOCIATE response primitive. The application-association is not established. The accepting RTPM does not issue an RT-OPEN indication. If the A-ASSOCIATE indication primitive and the RTORQ APDU parameters are acceptable to the accepting RTPM, it issues an RT-OPEK indication primitive to the acceptor. The RT-OPEN indication parameter values are derived from the RTORQ APDU and the A-ASSOCIATE indication primitive parameter values. The accepting RTPM waits for an RT-OPEN response primitive from the acceptor, or a primitive from the ACSE-provider. 7.1.3.3 RT-OPEN

If the application-association is rejected by the acceptor, the accepting RTPM forms a RTORJ APDU using the RT-OPEN response primitive parameters and internal data. The accepting RTPM issues an A-ASSOCIATE response primitive also using information from the RT-OPEN request primitive. The RTORJ APDU is sent as the user information parameter of the A-ASSOCIATE response primitive. The application-association is not established. 7.1.3.4 A-ASSOCIATE confirm primitive

The requesting RTPM receives an A-ASSOCIATE confirm primitive. The following situations are possible: a) b) c) the application-association accepted by the acceptor; has been

the accepting RTPM or the acceptor has rejected the application-association; or the ACSE service provider the application-association. has rejected

response primitive

When the accepting RTPM receives an RT-OPEN response primitive from the acceptor, the result parameter specifies whether the acceptor has accepted (value "accepted") or rejected the application-association. If the application-association is accepted by the acceptor, the accepting RTPM forms an RTOAC APDU using the RT-OPEN response primitive parameters and internal `data. The RT-OPEN response primitive parameters, except user-data, are stored by the accepting. RTPM for association-recovery. The accepting RTPM issues an A-ASSOCIATE response primitive also using information from the RT-OPEN response primitive. The RTOAC APDU is sent as the user information parameter of the A-ASSOCIATE response primitive.

If the application-association was accepted by the acceptor, the A-ASSOCIATE confirm primitive result parameter has the value "accepted" and the RTOAC APDU is the value of the user information parameter of the A-ASSOCIATE confirm primitive. The requesting RTPM issues. an RT-OPEN confirm primitive to the requestor. The result parameter has the value "accepted" and the user-data parameter contains the user-data parameter value of the RTOAC APDU. The other parameters of the RT-OPEK confirm primitive are derived from the A-ASSOCIATE confirm primitive. If the application-association was rejected by either the acceptor or the accepting RTP.M, the AASSOCIATE confirm primitive Result parameter has one of the values "rejected . ..". the AASSOCIATE confirm primitive result source parameter has the value "ACSE service-user" and the RTORJ APDU is the value of the user information parameter of the A-ASSOCIATE confirm primitive. The requesting RTPM issues an RT-OPEN confirm primitive to the requestor. The Result parameter has one of the values "rejected . . ." and the other parameter values are derived from the A-ASSOCIATE confirm primitive parameters and the RTORJ APDU. The application-association is not established.
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If the application-association was rejected by the ACSE service-provider, the A-ASSOCIATE confirm primitive result parameter has one of the values "rejected . . .", the A-ASSOCIATE confirm primitive result source parameter has either the value "ACSE service-provider" or "presentation service-provider". The user-data parameter of the RT-OPEN confirm primitive is absent and the application-association is not established. The other parameters of the RT-OPEN confirm primitive are derived from the A-ASSOCIATE confirm primitive, 7.1.4 Use of the RTORQ APDU fields

7.1.4.5

Session-connection-identifier

This field is used only in the association-recovery procedure. 7.1.4.6 Application-protocol

This field is used solely in the X.410-1984 mode. It is the application-protocol parameter value from the RT-OPEN request primitive. It appears as the application-protocol parameter value in the RTOPEN indication primitive. 7.1.5 Use of the RTOAC APDU fields

The RTOAC APDU fields are used as follows. 7.1.5.1 Checkpoint-size

The RTORQ APDU fields are used as follows, 7.1.4.1 Checkpoint-size The checkpoint-size field allows negotiation of the maximum amount of data (in units of 1024 octets) that may be sent between two minor synchronization points. If the checkpoint-size in the RTORQ APDU is greater than zero, the accepting RTP%I shall supply a value in the RTOAC APDU that is less than or equal to the value in the RTORQ APDC, else the accepting RTPM may select the checkpoint-size. A value of zero from the accepting RTPM indicates that checkpointing will not be used. The value of this field becomes. the agreed maximum value and governs both directions of transfer. If this field is absent, it is assumed that checkpointing will not be used. 7.1.5.2 Window-size

The checkpoint-size field allows negotiation of the maximum amount of data (in units of 1024 octets) that may be sent between two minor synchronization points. A value of zero from the requesting RTPM: invit,es the accepting RTPM to select checkpoint-size. If this field is absent, checkpoint-size zero is assumed. 7.1.4.2 Window-size

The window-size field allows negotiation of the maximum number of outstanding minor synchronization pomts before data transfer shall be suspended. If this field is absent, window-size 3 is assumed. 7.1.4.3 Dialogue-mode _

This is the dialogue-mode parameter value from the RT-OPEN request primitive. It appears as the dialogue-mode parameter value of the RT-OPEN indication primitive. The value of this field is either monologue, or twoway-alternate. If this field is absent, monologue is assumed. 7.1.4.4 User-data

This field is only used if checkpoint-size of the RTOAC APDC is greater than zero. The windowsize field allows negotiation of the maximum number of outstanding minor synchronization points before data transfer shall be suspended. The accepting RTPM shall supply a value that is less than or equal to the value in the RTORQ APDU. This becomes the agreed maximum size and governs both directions of transfer. If this field& absent, window-size 3 is assumed. 7.1.5.3 User-data

This is the user-data parameter value from the RT-OPEN request primitive. It appears as the user-data parameter value of the RT-OPEN indication primitive. The value of this field is transparent to the RTPM.

This is the user-data parameter value from the RT-OPEN response primitive. It appears as the user-data parameter value of the RT-OPEN confirm service primitive. The value of this field is transparent to the RTPM.
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7.1.5.4

Session-connection-identifier

This field is used only in the association-recovery procedure. 7.1.6 Use of the RTORJ APDU fields

This is the user-data parameter value of the RT-OPEN response primitive from the acceptor. It appears as the user-data parameter value of the RT-OPEN confirm primitive to the requestor. The value of this field is transparent 7.2 Ass,ociation-release Purpose to the RTPM.

The RT0R.J APDU fields are used as follows. 7i1.6.1 Refuse-reason field is only used in the X.4107.2.1

The refuse-reason 1984 mode.

This field may contain one of the following -

values:

The association-release procedure is used for the normal release of an an application-association by the association-initiator without loss of information in transit. 7.2.2 APDUs used

rts-busy: The accepting RTPM, or the acceptor, is so loaded that it cannot support a new application-association. The requesting RTPM should retry after a period of time. Thi$ value is either provided by the accepting RTPM, or is derived from the result parameter value "rejected (transient)" of the RT-OPEN response primitive from the acceptor. It appears as the result parameter value ,"rejected (transient)" of the RT-OPEN confirm primitive to the requestor. cannot-recover: This value is used only by the accepting RTPM in the associationrecovery procedure if it is unable to accept an association-recovery. validation-failure: The acceptor does not recognize the requestor's credentials as being valid for the proposed application-association. This value is the user-data parameter value of the RT-OPEN response primitive from the acceptor. It appears as the user-data parameter value of the RT-OPEX confirm primitive to the requestor. unacceptable-dialogue-mode: The acceptor does not accept the type of dialogue mode proposed for the application-association. This value is the user-data parameter value of the RT-OPEN response primitive from the acceptor. It appears as the user-data parameter value of the RT-OPEN confirm primitive to the requestor. User-data

No APDUs are used in this procedure. 7.2.3 Association-release procedure events: from. the

This procedure is driven by the following a1 an RT-CLOSE request primitive requestor (association-initiator) b) cl d) 7.2.3.1 an A-RELEASE

indication primitive from

-

an RT-CLOSE response primitive the acceptor (association-responder) an A-RELEASE RT-CLOSE confirm primitive. request primitive

-

-

The requestor may issue an RT-CLOSE request primitive only if it possesses the Turn and if there is no outstanding RT-TRA.SSFER confirm primitive. When an RT-CLOSE request primitive is received from the requestor, the requesting (association-initiating) RTPM issues an ARELEASE request primitive. The reason parameter of the A-RELEASE request primitive is the reason parameter of the RT-CLOSE request primitive. The user Information parameter of the A-RELEASE request primitive is the user-data parameter of the RT-CLOSE request primitive.
NOTE No RT-CLOSE present request primitive mode. parametp A are

in X.410-1984

The requesting RTPM waits for a primitive from the ACSE service-provider and does not accept any other primitive from the requestor.

7.1.6.2

This field is only used in the normal mode.
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7.2.3.2

A-RELEASE

indication primitive the A-RELEASE

The accepting RTPM receives indication primitive.

each application-association, or one interrupted activity may exist at a time.

at most one activity, awaiting resumption,

It issues an RT-CLOSE indication primitive to the acceptor. The RT-CLOSE indication parameter values are `derived from the A-RELEASE indication primitive.
NOTE No RT-CLOSE present indication primitive parameters are

in X.410-1984

mode.

The RTSE-user APDU value is transformed into the encoded-APDU-value and vice versa by means of the local syntax-matching services. The transfer procedure uses the RT-TRANSFER (RTTR) APDU. The transfer procedure supports segmenting and reassembling of the encodedAPDU-value into/from one or more RTTR APDUs. An encoded-APDU-value is transferred as a single RTTR APDU if checkpointing is not used. Otherwise, the encoded-APDU-value is transferred as a series of RTTR APDUs, the maximum size (i.e. number of octets forming the RTTR APDU value) of each being the negotiated checkpoint-size. The concatenation of the RTTR APDU values is the encoded-APDU-value. The fields of the RTTR APDU are listed in table 5. 7.3.3 Transfer procedure events: primitive

The RTPM waits for a primitive or the used service provider. 7.2.3.3 RT-CLOSE

from the acceptor

response primitive

When the accepting RTPM receives an RT-CLOSE response primitive, the accepting RTPM issues an A-RELEASE response primitive. The reason parameter of the A-RELEASE response primitive is the reason parameter of the RT-CLOSE response primitive. The user information parameter of the A-RELEASE response primitive is the user-data parameter of the RT-CLOSE response primitive.The result parameter value of the A-RELEASE response primitive is "affirmative".
NOTE No RT-CLOSE present response primitive parameters are

This procedure is driven by the following

a) an RT-TRANSFER
bl

request from the requestor (sender)

in X.410-1984

mode.

7.2.3.4

A-RELEASE

confirm primitive receives an A-RELEASE cl dl e) t-I

The requesting RTPM confirm primitive.

a P-ACTIVITY-START indication primitive, followed by one or more RTTR APDUs as user-data of P-DATA indication primitives each, except the last, followed by a P-MISOR-SYNCHRONIZE indication primitive a P-MINOR-SYNCHRONIZE primitive a P-ACTIVITY-END a P-ACTIVITY-END a Transfer Time-out. RT-TRANSFER request primitive indication confirm primitive

The requesting RTPM issues `an RT-OPEN confirm primitive to the acceptor. The RT-OPEN confirm primitive parameter values are derived from the A-RELEASE confirm primitive.
NOTE No RT-CLOSE present confirm primitive parameters are

confirm primitive

in X.410-1984mode.

7.3.3.1

7.3 7.3.1

Transfer Purpose

The transfer procedure is used to transfer an RTSE-user APDU from the requestor (sender) to the acceptor (receiver). 7.3.2 APDUs used

If the requesting RTPlM possesses the Turn and receives a RT-TRANSFER request from the requestor, the requesting RTPLM transforms the RTSE-user APDU value into the encoded-APDUvalue by means of the encoding service of the local syntax-matching services. The requesting RTPM issues a P-ACTIVITYSTART request primitive and may start transmitting the first RTTR APDU in a P-DATA request primitive immediately after the

Each RTSE-user APDU, conveyed in an RTTRANSFER request, constitutes an activity. For
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Table 5 - RTTR APDU fields

I

I

I

I

I
I

1
Sink ind/conf
I

Field name User-data-part

I
I

Presence M

I I .

Source
=eq

I I .

I

I
I

P-ACTIVITY-START request primitive is issued, since the latter service is not a confirmed service. The maximum RTTR APDU size will have been negotiated during the association-establishment procedure. The requesting RTPM shall submit, in P-DATA request primitives, RTTR APDUs that conform to that agreemenit. Checkpoints may only be inserted if a checkpoint-size greater, than zero was negotiated during the associationestablishment procedure. If a transferred RTTR APDU is not the last in a series of RTTR, APDUs used to transfer a single encoded-`APDU-value, the requesting RTPM inserts a checkpoint by issuing a P-MINORSYNCHRONIZE request primitive. The requesting RTPM uses only the "exp1ici.t confirmation expected" type of minor synchronization. The requesting RTPM may issue further P-DATA request primitives and PMINOR-SYNCHRONIZE request primitives unless the agreed window-size has been reached. If the RTTR APDU is the only one, or the last in a series of RTTR APDUs used to transfer a single encoded-APDU-value, the requesting RTPM issues a P-ACTIVITY-END request primitive. Consecutive P-DATA request primitives shall not be issued, and all data transfer shall take place within an activity. 7.3.3.2 P-ACTIVITY-START indication primitive, RTTR APDUs, and PMINOR-SYNCHRONIZE indication primitives

RTPM receives a RTTR APDU as user-data P-DATA indication primitive.

of a

If the RTTR APDU is not the last in a series of RTTR APDUs used to transfer a single encodedAPDU-value, the accepting RTPM receives a PMINOR-SYNCHRONIZE indication primitive. If the accepting RTPM has secured the RTTR APDU, it issues a P-MINOR-SYNCHRONIZE response primitive. 7.3.3.3 P-MINOR-SYNCHRONIZE primitive Tonfirm

When the requesting RTPM receives a P-MINORSYNCHRONIZE confirm primitive, it assumes that the accepting RTPM has secured the encodedAPDU-value APDU up to that point. The requesting KTPM may issue further P-DATA P-MINOR ' request primitives and SYNCHRONIZE request primitives unless the agreed window-size has been reached. The window is advanced when a `P-MINORSYNCHRONIZE confirm primitive is received by the requesting RTPM. When a complete encoded-APDU-value has been transmitted, the requesting RTPM issues a PACTIVITY-END request primitive. 7.3.3.4 P-ACTIVITY-END' primitive indication

The accepting RTPM receives a P-ACTIVITYSTART indication primitive, indicating the start of transfer of a RTSE-user APDU. The accepting

A P-ACTIVITY-END indication primitive indicates to the accepting RTPM that a complete encoded-APDU-value has been transferred. The accepting RTPM transforms the encoded-APDUvalue into the RTSE-user APDU value'by .means of the decoding service of the local syntaxmatching-services.
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If the accepting RTPM has secured the complete RTSE-user APDU, it issues an RT-TRANSFER indication primitive to the acceptor, and issues a P-ACTIVITY-END response primitive. The accepting RTPM records the sessionconnection-identifier and the activity identifier of the last RTSE-user APDU which it completely secured for association-recovery purposes. 7.3.3.5 P-ACTIVITY-END primitive confirm

7.4.2

APDUs

used uses the RT-TURN-

The turn-please procedure PLEASE (RTTP) APDU.

The fields of the RTTP APDU are listed in table 6. 7.4.3 Turn-please Procedure events: primitive

This procedure is driven by the following al b) an RT-TURN-PLEASE from the requestor an RTTP APDU TOKEN-PLEASE request

An activity end is an implicit major synchronization point and once successfully confirmed by means of an P-ACTIVITY-END confirm primitive, it indicates to the requesting RTPM that the RTSE-user APDU has been secured by the accepting RTPM. The requesting RTPM may then delete the transferred RTSE-user APDU. When the requesting RTPM receives the PACTIVITY-END confirm primitive, it issues an RT-TRANSFER confirm primitive with a result parameter value of "APDU-transferred" to the requestor. 7.3.3.6 Transfer Time-out

as user-data of a Pindication primitive. request

7.4.3.1

RT-TURN-PLEASE primitive

If the requesting RTPM does not possess the Turn and receives an RT-TURN-PLEASE request from the requestor, the requesting RTPM issues a PTOKEN-PLEASE request primitive. If the priority parameter is present in the RT-TURNPLEASE request primitive, an RTTP APDC is formed from the parameter value and transferred as user-data of the P-TOKEN-PLEASE request primitive. This procedure may be performed either inside or outside an activity. 7.4.3.2 RTTP APDU

If an APDU has not been transferred within the time specified in the transfer-time parameter of the RT-TRANSFER request primitive (that is, the requesting RTPM has not received the PACTIVITY-END confirm primiti;e), the requesting RTPM performs the transfer-discard procedure followed by the transfer-abort procedure. If during the transfer-discard procedure, the requesting RTPM does not receive a P-ACTIVITY-DISCARD confirm primitive within a (locally specified) reasonable time, the requesting RTPM performs the transfer-abort procedure followed by the provider-abort procedure. 7.4 7.4.1 Turn-please Purpose

If the accepting RTPM receives a P-TOKENPLEASE indication primitive, the accepting RTPM issues an RT-TURN-PLEASE indication primitive to the acceptor. If an RTTP APDU is transferred as user-data of the P-TOKENprimitive, the PLEASE indication RT-TURX-PLEASE indication primitive parameter is present and derived from the RTTP APDC. 7.4.4 Use of the RTTP fields

The RTTP APDU fields are used as follows. 7.4.4.1 Priority

This is the priority parameter value of the RT-TURN-PLEASE request primitive. It appears as the priority parameter value of the RT-TURN-PLEASE indication primitive. The value of this field is transparent to the RTPM.

The turn-please procedure is used by a receiver (requestor) to request the Turn from the sender (acceptor).

12

IS13707(Part2):1993 Iso/ IEC 9066-2 -A989

Table 6 - RTTP APDU fields

Field name Priority

Presence U

Source req

Sink ind

7.5 7.5.1

Turn-give Purpose

7.5.3.1

RT-TURN-GIVE

request primitive

The turn-give procedure is used by a sender (requestor) to give the Turn to the receiver (acceptor). The requestor becomes the receiver and theacceptor becomes the sender. 7.5.2 APDUs used

If the requesting RTPM possesses the Turn and receives an RT-TURN-GIVE request primitive from the requestor, it issues a P-CONTROL-GIVE request primitive and becomes the receiving RTPM. This may be done only outside an activity. 7.5.3.2 P-CONTROL-GIVE primitive indication

No APDUs are used in this procedure. 7.5.3 Turn-give procedure is driven by the following request primitive indication

The turn-give events: al bl

procedure

an RT-TURY-GIVE

If the accepting RTPM receives a P-CONTROLGIVE indication primitive, the accepting RTPM issues an RT-TURN-GIVE indication primitive to the acceptor, and issues a P-CONTROL-GIVE response primitive.The accepting RTPM becomes the sending RTPM.

a P-CONTROL-GIVE primitive.
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7.6

Error reporting User-exception-report Purpose

7.6.1.3.2

7.6.1 7.6.1.1

P-U -EXC EPT I0 N-R E P 0 RT indication primitive

The user-exception-report procedure is used by the receivingRTPM to report an error situation to the sending RTPM. 7.6.1.2 APDUs used

receives a RTPM If the sending P-U-EXCEPTION-REPORT indication primitive, it performs one of the following procedures depending on the reason parameter value of the P-U-EXCEPTION-REPORT indication primitive:
a)

No APDIJs are used in this procedure. 7.6.1.3 User-exception-report procedure
b)

"receiving With a value jeopardized", the transfer-abort followed by the provider-abort are performed.

ability procedure procedure

This procedure al

is driven by the following events: RTPM problem indication
c)

a receiving

With a value "unrecoverable procedure procedure error", the transfer-discard followed by transfer-retry procedure are performed. With a value "non-specific error", the transfer-discard procedure followed by the transfer-abort procedure are performed. With a value "sequence error", the transfer-discard procedure is performed and the requesting RTP,M issues an RT-TRAI;SFER confirm primitive with a Result parameter value of "APDUto the requestor and the transferred" transfer procedure is finished. With a value "local SS-User error" and at least one confirmed checkpoint in the transfer procedure, the transfer-interrupt procedure followed by the transferresumption procedure are performed. If no checkpoint was confirmed in the transfer procedure, the transfer-discard procedure followed by the transfer-retry procedure are performed. Provider-exception-report Purpose

b) a P-U-EXCEPTION-REPORT primitive. 7.6.1.3.1 Receiving RTPM problem

If the receiving RTPM detects a problem, it issues a P-U-EXCEPTION-REPORT request primitive and starts a local recovery timer. Depending on the severity of the detected error, the value of the reason parameter of the PU-EXCEPTION-REPORT request primitive is as follows:
a)

dl

In severe problem situations, "receiving ability jeopardized"

the value is used.

e)

circumstances, the b) `In exceptional receiving RTPM may have to delete a partially received RTSE-user APDU, even though some minor synchronization points have been confirmed. In this case, "unrecoverable procedure the value error" is used. cl. If the receiving RTPM is not willing to complete a transfer procedure, the value "non-specific error" is used. 4 If the sending RTPM resumes a transfer procedure already finished by the receiving RTPM (see 7.8.1.3.21, the value "sequence error" is used. For all other less severe error situations, the value "Iocal SS-User error" is used.
7.6.2 7.6.2. I

e)

If the presentation service-provider detects an unexpected situation during an activity, not services, a covered other by P-P-EXCEPTION-REPORT indication primitive is issued to both RTPMs. 7.6.2.2 APDUs used

No APDUs are used in this procedure.
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7.6.2.3

Provider-exception-report procedure is driven by the following events: indication

7.7.1.3.1 Sending RTPM

problem

This procedure a)

a P-P-EXCEPTION-REPORT primitive.

7.6.2.3.1

P -P -E XC E P T I 0 N -R E P 0 RT indication PrSmitive RTPM ignores indication primitive. a

If the sending RTPM detects a less severe problem and at least one checkpoint was confirmed during the transfer procedure, it issues a P-ACTIVITY-INTERRUPT request primitive with one of the following reason parameter values: a) b) "non-specific error", indicated by an error if the problem was r'eporting procedure; is a

The receiving P-P-EXCEPTION-REPORT

"local SS-User error", if the problem local sending RTPiM problem.

RTPM If the receives a sending P-P-EXCEPTION-REPORT indication primitive, it may perform one of the following procedures: a) if at least one checkpoint was confirmed in the transfer procedure, the transferinterrupt procedure followed by the transfer-resumption procedure, or if no checkpoint was confirmed in the transfer procedure, the transfer-discard procedure followed by the transfer-retry procedure, or the transfer-abort the provider-abort Error handling procedure procedure. followed by

7.7.1.3.2

P - A CT I V I T Y - I N T E R R U P T indication primitive

RTPM receives a If the receiving P-ACTIVITY-INTERRUPT indication primitive, it issues a P-ACTIVITY-INTERRUPT response primitive and starts a local recovery timer. 7.7.1.3.3 P-ACTIVITY-INTERRUPT primitive confirm

b)

c)

RTPM receives If the sending P-ACTIVITY-INTERRUPT confirm primitive, starts the transfer-resumption procedure. 7.7.2 7.7.2.1 Transfer-discard Purpose

a it

7.7 7.7.1 7.7.1.1

Transfer-interrupt Purpose

The transfer-interrupt procedure is used by the sending RTP_M to handle a less severe (than those handled by the other error handling procedures) error situation during the transfer procedure, if at least one checkpoint was confirmed during the transfer procedure. 7,.7.1.2 No APDUs 7.7.1.3 APD Us used are used in this procedure. Transfer-interrupt is driven RTPM procedure events:

The transfer-discard procedure is used by the sending RTPM to escape from a more severe (than those handled by the transfer-interrupt procedure) error situation, or a less severe error situation if no checkpoint was confirmed, during the transfer procedure. 7.7.2.2 No APDUs 7.7.2.3 APDUs used

are used in this procedure Transfer-discard is driven procedure by the following events:

This procedure a) b) a sending

This procedure a) b) a sending

by the following problem;

RTPM problem; indication

a P-ACTIVITY-DISCARD primitive; a P-ACTIVITY-DISCARD primitive.

a P-ACTIVITY-INTERRUPT primitive; a P-ACTIVITY-INTERRUPT primitive.

indication

c)

confirm

c)

confirm
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7.7.2.3.1

Sending

RTPM

problem

NOTE

The RTAB APDU

is also used by the provider-abort

If the sending RTPM detects a more severe problem, or a less severe problem if no checkpoint was confirmed during the transfer procedure, it issues a P-ACTIVITY-DISCARD request primitive with one of the following reason parameter values: a) b) "non-specific error", if the problem was indicated by an error reporting procedure, "local %-User error", or "unrecoverable procedural error", if the problem is a local sending RTPM problem. P-ACTIVITY-DISCARD primitive indication

and the user-abort procedure.

7.7.3.3

Association-abort

procedure events:

This procedure is driven by the following a) bl 7.7.3.3.1 an RTPM-abort an RTAB APDU. RTPM-abort

7.7.2.3.2

If the receiving RTPM receives a P-ACTIVITY-DISCARD indication primitive, it issues a P-ACTIVITY-DISCARD response primitive. The receiving RTPM deletes all knowledge and contents of the associated RTSE-user APDU so far received.

Either the receiving or the sending RTPM transfers an RTAB APDU to its peer as user-data of an A-ABORT request primitive. If the RTPM is the association-initiating RTPM, it performs the association recovery procedure. If the RTPM is the association-responding RTPM, it awaits association-recovery. The receiving RTP;M starts a local recovery timer. After successful association recovery, the sending RTPM performs the transfer-resumption procedure. 7.7.3.3.2 RTAB APDU

If the receiving RTP-M has already issued an RTTRANSFER indication primitive, it performs the association-abort procedure. The abort-reason field value of the RTAB APDU is "transfercompleted". In this case the sending RTP%l ends the transfer procedure with a positive RTTRANSFER confirm primitive and the association-recovery procedure is performed.
7.7.2.3.3 P-ACTIVITY-DISCARD primitive confirm

Either the sending RTP,M or the receiving RTPM may receive an RTAB APDU as user-data of an A-ABORT indication primitive. If the RTPM is the association-initiating RTPM, it performs the association-recovery procedure. If the RTPIM is the association-responding RTPIM, it awaits association recovery. The receiving RTP.M starts a local recovery timer. After successful association recovery, the sending RTPM performs the transfer-resumption procedure. 7.7.3.4 Use of the RTAB APDU fields

The receipt of a P-ACTIVITY-DISCARD confirm primitive by the sending RTPM signifies the completion of the transfer-discard procedure. 7.7.3 7.7.3.1 Association-abort Purpose

The RTAB APDU fields are used as follows: 7.7.3.4.1 Abort-reason values:

The association-abort procedure is used by the RTPMs to handle the most severe error situations. This procedure can be performed between an RTTRANSFER request primitive and its corresponding RT-TRANSFER confirm primitive. 7.7.3.2 APDUs'used

This field may contain one of the following local-system-problem; invalid-parameter: parameters are reflected-parameter the specified

invalid in the

field;

The association-abort procedure uses the RT-ABORT (RTAB) APDU. The fields of the RTAB APDU are listed in table 7.

-

unrecognized-activity: the sending RTPM shall perform the transfer-abort procedure optionally followed by the provider-abort procedure;
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Table 7 - RTAB APDU fields

Field name

Presence

Source
SP

Sink
SP

I
-

Abort-reason Reflected-parameter User-data

T

temporary-problem: no attempt at association-recovery should be made for a period of time determined by a local rule; protocol-error: of the RTPM;

The association-provider-abort to handle an ACSE-provider, service-provider abort. 7.7.4.2
APDUs used

procedure is used or a presentation

permanent-error: this value is used solely by the provider-abort procedure in normal mode; user-abort: this value is used solely by the user-abort procedure in normal mode; transfer-completed: could not discard transfer. the receiving RTPM an already completed

No APDUs are used in this procedure.

7.7.4.3

-

Association-provider-abort procedure

This procedure a) 7.7.4.3.1

is driven by the following event: primitive.

an A-P-ABORT indication
A-P-ABORT

indication primitive

7.7.3.4.2

Reflected-parameter

The reflected-parameter field is a bit string that identifies which parameters are regarded as invalid garameters in the primitive received from the used service by the aborting RTP_M before the association-abort. The order of the bits in the bit string is the same as the order of the parameters in the tables of service paramet.ers in IS0 8649 the. first and IS0 8822 (i.e. bit 1 represents parameter, etc). 7.7.3.4.3
User-data

An association-provider-abort RTPMs by an A-P-ABORT and may occur at any time.

is indicated to both indication primitive,

After such an event, the association-initiating RTPM starts the association-recovery procedure. Both RTP>Is start a local recovery timer. If the association-provider-abort procedure was performed during the transfer procedure, the sending RTP.M starts the transfer-resumption procedure after the association-recovery procedure is successfully completed. If the. association-recovery procedure was not successfully completed, the sending RTPM performs the transfer-error procedure, and the provider-abort procedure.

This field is not used in the association-abort procedure: 7.7.4
7.7.4.1 Association-provider-abort Purpose
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7.8 7.8.1 7.8.1.1

Error recovery Transfer-resumption Purpose procedure from is used by the

the transfer-discard procedure followed transfer-retry procedure are performed. 7.8.1.3.2 P-ACTIVITY-RESUME Primitive

by the

Indication

The transfer-resumption sending RTPM to recover a) an error interrupt

situation handled procedure, or

by the transfer-

b)

an error situation handled by the association-abort procedure during a transfer procedure. In this case the transfer-resumption procedure is performed after an association-recovery procedure is successfully performed. If no checkpoint was confirmed in the interrupted transfer procedure, the transfer-discard procedure followed by the transfer-retry procedure are performed after transfer-resumption. APDUs used procedure uses the

If the receiving RTPM receives a P-ACTIVITY-RESUME indication primitive, it checks the old activity identifier and the old session connection identifier parameters of the P-ACTIVITY-RESUME indication primitive with the corresponding information (sessionconnection-identifier, and activity identifier) recorded for the last completely secured transfer (see 7.3.3.4). If the information coincides, the receiving RTPM either (a) responds correctly to the sending RTPM according to the transfer procedure, but discards the data it receives, and does not issue an RT-TRANSFER indication primitive, or (b) performs the user-exception-report procedure with a reason parameter value of "sequence error". If the information does not coincide, and the old activity identifier and the old session connection identifier parameter match the corresponding information of the previously interrupted activity, the transfer-resumption procedure continues as for the transfer procedure with a P-DATA indication primitive for the RTTR APDC following the last confirmed checkpoint. If the receiving RTPLI cannot the receiving RTPM performs report procedure or the procedure. 7.8.2 7.8.2.1 Transfer-retry Purpose resume the activity, the user-exceptionassociation-abort

7.8.1.2

The transfer-resumption RTTR APDU (see 7.3.2). 7.8.1.3 Transfer-resumption is driven

procedure events: Activity; indication

This procedure a) b)

by the following of an interrupted

the resumption

a P-ACTIVITY-RESUME primitive.

After these events, the transfer to continue (see 7.3.3). 7.8.1.3.1 Resumption activity of

procedure

is used

an

interrupted

The sending P-ACTIVITY-RESUME parameters that link previously interrupted

RTPM request the resumed one.

issues primitive activity

a with to the

After the sending RTPM has issued the P-ACTIVITY-RESUME request primitive and at least one checkpoint was confirmed in the interrupted transfer procedure, it continues the transfer procedure by issuing a P-DATA request primitive for the RTTR APDU following the last confirmed checkpoint. If no checkpoint was confirmed in the interrupted transfer procedure,

The transfer-retry procedure is used by the sending RTP,M to recover from an error situation handled by the transfer-discard procedure The completion of this transfer procedure. 7.8.2.2 APDUs used procedure uses the RTTR procedure is as for the

The transfer-retry APDU (see 7.3.2)
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7.8.2.3

Transfer-retry

procedure

The following a) bl 7.8.3.3

rules apply: in

The sending RTPM performs the transfer procedure (see 7.3.3). A new activity identifier the valLe is ,used in parameter P-ACTIVITY-START request primitive. 7.8.3 7.8.3.1 Association-recovery Purpose

The refuse-reason field is used solely .the X.410-1984 mode; The user-data field is not used. Association-recovery procedure events:

This procedure is driven by the following a) b) cl

The association-recovery procedur e is used by the association-initiating RTPM to recover from an error situation handled by the association-abort procedure or the association-provider-abort procedure. 7.8.3.2 APDUs used

an A-ASSOCIATE request primitive the association-initiating RTPM;

by

an RTORQ APDU as user-data on an AASSOCIATE indication primitive; an A-ASSOCIATE confirm primitive that may contain either an RTOAC APDU, or an RTORJ, or no APDU. A-ASSOCIATE request primitive

The association-recovery procedure uses the RT-OPEN-REQUEST (RTORQ) APDU, the RTzOPEN-ACCEPT (RTOAC) APDU, and the RT-OPEir;-REJECT (RTORJ) APDU. 7.8.3.2.1 RTORQ APDU

7.8.3.3.1

The RT-OPEFi-REQUEST (RTORQ) APDC is used in the request to recover an applicationassociation. The fields of the RTORQ APDU are listedin 7.1.2.1. The following a) b) rules apply:

The association-initiating RTPM forms an RTORQ APDU from its internal data. The association:initiating RTPM issues an AASSOCIATE request primitive using information stored during the association-establishment procedure (see 7.1.3.11. The RTORQ APDU is the user Information parameter value of the A-ASSOCIATE request primitive. The association-initiating RTPM waits primitive from the ACSE service-provider. for a

the user-data field is not used; the session-connection-identifier mandatory. RTOAC APDU field is 7.8.3.3.2 RTORQ APDU If the application-association is not accepted by the ACSE service-provider, no A-ASSOCIATE indication primitive is received by the associationresponding RTPM and no action takes place. If the application-association is accepted by the ACSE service-provider, the associationresponding RTPM receives the RTORQ `APDU as the user information parameter on an A-ASSOCIATE indication primitive. If any of the A-ASSOCIATE indication primitive parameters, or any of the RTORQ APDU fields, is unacceptable to the association-responding RTPM, or if the association-responding RTPM is not able to accept the application-association, it -forms and sends an .RTORJ APDU with appropriate parameters from internal data. The association-responding RTPM issues an AASSOCIATE response primitive. The RTORJ APDU is sent as the user information parameter

7.8.3.2.2

The RT-OPEN-ACCEPT (RTOAC) APDU is used `. m the positive response to the request to recover an application-association. The fields of the RTOAC APDU are listed in 7.1.2.2. The following
a)

rules apply:

the user-data field is not used; field is mandatory.

b) the session-connection-identifier
7.8.3.2.3 RTOR J APDU

The RT-OPEN-REJECT (RTORJ) APDU is used in the negative response to the request to recover an application-association. The fields of the RTORJ APDU are listed in 7.1.2.3.
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of the A-ASSOCIATE application-association

response primitive. is not recovered.

The

"presentation service-provider". association is not recovered.

The application-

If the A-ASSOCIATE indication primitive parameters, and the RTORQ APDU fields are acceptable to the association-responding RTPM, the association-responding RTPM forms an RTOAC APDU using internal data. The association-responding RTPM issues an AASSOCIATE response primitive. The RTOAC APDU is sent as the user information parameter of the A-ASSOCIATE response primitive. 7.8.3.3.3 A-ASSOCIATE confirm primitive RTPM receives an primitive. The following `has has rejected been the

If the application-association was not recovered, the association-recovery procedure is performed again by the association-initiating RTPM after a time determined by a local rule:
a)

if the result parameter of the A-ASSOCIATE confirm primitive has the following value "rejected (transient)"; or if, in X.410-1984 mode, the refuse-reason field of the RTORJ APDU has the value "rts-busy". is performed as

bl

The association-initiating A-ASSOCIATE confirm situations are possible:
a)
Q

In-all other cases a provider-abort follows.

the association-recovery accepted; RTPM association-recovery;or

b) the accepting
cl

the ACSE service provider the association-recovery.

has rejected

If the association-initiating RTP;M is the sending RTPM, and the association-abort occurred during the transfer procedure, the sending RTPM performs the transfer-abort procedure. The association-initiating RTPM performs the provider-abort procedure. If the association-responding RTPN detects a recovery-time-out, the following actions tak'e place. If the association-responding RTPM is the sending RTP&I, and the association-abort occurred during the transfer procedure, the sending RTPM performs the transfer-abort procedure. The association-responding RTPN performs the provider-abort procedure. 7.8.3.4 Use of the RTORQ APDU fields

If the association-recovery was accepted, the AASSOCIATE confirm primitive result parameter has the value "accepted" and the RTOAC APDC is the value of the user information parameter of the A.-ASSOCIATE confirm primitive. The application-association is recovered successfully, and if the association-abort occurred during the transfer procedure, the sending RTPM continues with the transfer-resumption procedure. If the association-recovery was rejected by the responding RTPM, the A-ASSOCIATE confirm primitive result parameter has one of the values confirm "rejected . ..". the A-ASSOCIATE primitive result source parameter has the value "ACSE service-user" and the RTORJ APDU is the value of the user information parameter of the A-ASSOCIATE confirm primitive. The application-association is not recovered. If the association-recovery was rejected by the ACSE service-provider, the A-ASSOCIATE confirm primitive result parameter has one of the values "rejected . .." and the A-ASSOCIATE confirm primitive result source parameter has either the value "ACSE service-provider" or

The RTORQ APDL' fields are used as follows. 7.8.3.4.1 See 7.1.4.1. 7.8.3.4.2 See 7.1.4.2. 7.8.3.4.3 See 7.1.4.3. 7.8.3.4.4 User-data Dialogue-mode Window-size Checkpoint-size

This field is not used in the association-recovery procedure.
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7.8.3.4.5

Session-connection-identifier

The session-connection-identifier is used to specify the original session connection used in the association-establishment procedure.?This is used in order to relate the new session-connection to the existing application-association. 7.8.3.6.4 7.8.3.5 Use of the RTOAC APDU fields The RTOAC APDU fields are used as follows. 7.8.3.5.1 See 7.1.5.1. 7.8.3.5.2 Window-size Checkpoint-size

provided RTPM.

by the

association-responding

cannot-recover: This value is used by the association-responding RTPM, if it is .unable to accept an association-recovery. User-data is not used in the association-recovery

This field procedure. 7.9

Abort when error a successful handling

These procedures are performed recovery from one of the procedures is not possible. 7.9.1 7.9.1.1 in the association-recovery Transfer-abort Purpose

See 7.1.5.2. 7.8.3.5.3 This field procedure. 7.8.3.5.4 User-data is not used

The transfer-abort procedure sending RTPM if the transfer APDL is not possible. 7.9.1.2 No APDLs 7.9. L.3 APDCs used

is used by the of an RTSE-user

Session-connection-identifier

The session-connection-identifier is used to specify the original session connection used in the association-establishment procedure. This is used in order to relate the new session-connection to the existing application-association. 7.8.3.6 The RTORJ 7.8.3.6.1 Use of the RTORJ APDU APDU fields

are used in this procedure. Transfer-abort procedure

fields are used as follows

The sending RTPM issues an RT-TRANSFER confirm primitive with a result parameter value "APDC-not-transferred". The APDU parameter value is the RTSE-user APDG not transferred. 7.9.2 Provider-abort Purpose procedure :s used is not possible. used by the

Refuse-reason field is used solely in the X.410-

The refuse-reason 1984 mode.

7.9.2.1

This field may contain -

one of the following

values:

The provider-abort RTP%s, if recovery 7.9.2.2 APDUs

rts-busy: The association-responding RTPM is so loaded that it cannot support the application-association. The association-initiating RTPM should retry after a period of time. This value is

If an application-association exists, the providerabort procedure uses the RT-ABORT (RTAB) APDU. The RTAB APDL is specified in 7.7.3.2.
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7.9.2.3

Provider-abort

procedure

This procedure a) b) c) 7.9.2.3.1

is driven by the following events:

The user-abort (RTAB) APDU. 7.7.3.2. 7.9.3.3

procedure uses the RT-ABORT The RTAB APDU is specified in

an RTPM-abort: an RTAB APDU; local recovery RTPM-abort b) time-out. User-abort procedure This procedure a) is driven by the following events: request primitive from

an RT-U-ABORT the requestor;

If an -application-association exists, either the receiving or the sending RTPM transfers an RTAB APDU to its peer as the user-data parameter of an A-ABORT request primitive. The RTPM issues a RT-P-ABORT indication primitive to its RTSE-user. 7.9.2.3.2 RTAB APDU

an RTAB APDU as User-data ABORT indication primitive. RT-U-ABORT request

of an A-

7.9.3.3.1

If the sending or. the receiving RTPM receives an RTAB APDU as the user-data parameter of an A-ABORT indication primitive, it issues an RT-PABORT indication primitive to its RTSE-user. 7.9.2.3.3 Recovery time-out

If the requesting RTPM receives an RT-U-ABORT request primitive from the requestor, an RTAB APDU is formed from the parameter value of the RT-U-ABORT request primitive and transferred as user-data of an A-ABORT, request primitive.
7.9.3.3.2 RTAB APDU

If an application-association does not exist and a local recovery time-out occurs, the RTPM issues an RT-P-ABORT indication primitive to its RTSE-user. 7.9.2.4 Use of the RTAB APDU fields

If the accepting RTPM receives the RTAB APDU as user-data of an A-ABORT indication primitive, the accepting RTP,M issues an RT-U-ABORT indication primitive to the acceptor. The RT-U-ABORT indication primitive parameter is derived from the RTAB APDL'
7.9.3.4 Use of the RTAB'APDU fields

The RTAB APDU fields are used as follows. 7.9.3.4.1 Abort-reason

The RTAB APDU fields are used as follows 7.9.2.4.1 Abort-reason The value of this field is "user-error" 7.9.3.4.2 7.9.2.4.2 Reflected-parameter This field is not used. 7.9.3.4.3 7.9.2.4.3 User-data This field is not used. 7.9.3 7.9.3.1 User-abort Purpose User-data This is the user-data parameter value of the RT-U-ABORT request primitive. It appears as the user-data parameter value of the RT-U-ABORT indication primitive. 7.10 Rules for extensibility Reflected-parameter

The value of this field is "permanent-error" This field is not used.

The user-aboct procedure is used by the requestor to abort an application-association. . 7.9.3.2 APDUs used

In addition to the procedures stated above the following rule also applies when processing APDUs defined in this part of ISO/IEC 9066: Ignore parameters which are not defined in this part bf ISO/IEC 9066 for RTORQ, RTOAC, and RTORJ APDUs.
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8

Mapping to used services.
how an RTPM transfers

This clause defines APDUs by means of a) b)

The association-establishment procedure place concurrently with the underlying association establishment. 8.1.1.1.1 Directly mapped parameters

takes ACSE

the ACSE services, or the presentation-service.

Subclause 8.1 defines the mapping on the ACSE services, and 8.2 defines the mapping on the presentation-service. Identification of the named abstract syntax in use is assumed for all RTSE services and is mapped onto used services, however this is a local matter and outside the scope of ISO/IEC 9066. 8.1 Mapping on the ACSE Services

The following parameters of the RT-OPEN service primitives are mapped directly onto the corresponding parameters of the A-ASSOCIATE service primitives:

a) Mode
b) c) d) e) f, g) h) il j) Application Context Name

Calling AP Title Calling AP Invocation-identifier Calling Calling Called Called Called Called AE Qualifier AE Invocation-identifier AP Title AP Invocation-identifier AE Qualifier Al? Invocation-identifier AP Title AP tnvocation-identifier AE Qualifier AE Invocation-identifier

This subclause defines how the ACSE service primitives described in IS0 8649 are used by the RTPM. Table 8 defines the mapping of the RTSE service primitives and APDUs to the ACSE service primitives. Subclause 8.1.1 defines the mapping onto ACSE in normal mode. Subclause 8.1.2 defines the mapping onto ACSE in X.410-1984 mode. 8.1.1 8.1.1.1 Mapping on the ACSE normal mode Association-establishment procedure Services in

k) 1) ml n) 01 p) ql

Responding Responding Responding Responding Result

Source

Diagnostic Calling Presentation Address

Table 8 - ACSE

mapping

overview

RTSE service RT-OPEN request / indication RT-OPEN response /confirm RT-OPEN response /confirm RT-CLOSE request/indication RT-CLOSE response /confirm association-abort association-provider-abort RT-P-ABORT indication RTlU-ABORT request / indication I

APDU RTORQ RTOAC RTORJ

ACSE service A-ASSOCIATE request / indication A-ASSOCIATE response /confirm A-ASSOCIATE response /confirm A-RELEASE request 1 indication A-RELEASE response /confirm A-ABORT request / indication A-P-ABORT indication A-ABORT request/ indication A-ABORT request/ indication

RTAB RTAB RTAB
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r) s) t)
UJ

Called Presentation Responding Presentation Presentation List

Address Address List Result

Presentation

session-connection turn parameter primitive.

phase, according to the initialof the RT-OPEN request

Context Definition Context Definition

VI w)

Default Presentation Default Presentation Parameters

Context Name Context Result.

The association-initiating RTPM shall assign all of the tokens to the same RTPM. The application-association may be rejected if this rule is violated. At any particular point in time, the holder of the tokens is referred to as the sending RTPM, the other as the receiving RTPM. 8.1.1.1.3.5 Session connection identifier

8.1.1.1.2

not used A-ASSOCIATE

The following parameters of the service primitives are not used: a) b) Presentation requirements

Initial synchronization number.

point

serial

8.1.1.1.3

Use of the other A-ASSOCIATE request and indication primitive parameters User information

8.1.1J.3.1

The association-initiating RTPM will supply a session connection identifier, which will be used to This uniquely identify the session-connection. identifier is formed of the following components: SS-User Reference, Common Reference, and, optionally, Additional Reference Information. The SS-User Reference is conveyed as the Calling SSUser Reference by the association-initiating RTPM. Common Reference and Additional Reference Information are conveyed in similarly named parameters of the P-CONNECT primitive. Each component, when present, data element of the appropriate following definitions:
CaliingSSuserRe~erence T61 String OCTET STRING :: = CHOICE( ,-- solely --

For both the A-ASSOCIATE request and indication primitives, the user information parameter is used to carry the RTORQ APDU. 8.1.1.1.3.2 Quality of Service

shall contain a type from the

The parameters "Extended Control" and "Optimized Dialogue Transfer" are set to "not The remaining .parameters are set required." such that default values are used. 8.1.1.1.3.3 Session requirements

in X.410-1984

mode --

solely in normal mode -- )
:: = UTCTime :: = T61String

CommonReference AdditionalReferencelnformation

This parameter is set by the association-initiating RTPM to select the following functional units: a) b) c) d) Half-duplex Exceptions functional unit

8.1.1.1.4 Use of the other A-ASSOCIATE response and confirm primitive parameters 8.1.1.1.4.1 User information

functional unit functional unit unit.

Minor synchronize Activity

NOTE

This

parameter

only

has

relevance

if the

management

functional of tokens

application-association service-provider.

is accepted

by the ACSE

8.1.1.1.3.4

Initial assignment

The association-initiating RTPM will always request that the data token be available for either monologue or two-way alternate interactions. The association-initiating RTPM will specify which RTPM will initially hold the data token (minor synchronize token and major/activity token) upon successful completion of the

For both the A-ASSOCIATE response and confirm primitives, the user information parameter is used to carry the RTOAC APDU, if the application-association is accepted; or the RTORJ APDU, if the application-association is rejected by either the association-responding RTPM, or the association-responder.
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8;1.1.1.4.2 Result For the A-ASSOCIATE response primitive the result parameter is set by the associationresponding RTPM as follows: a) If the association-responding RTPM rejects the application-association, the value of this parameter is set to either "rejected (transient)" or "rejected (permanent)" If the association-responding RTPM accepts the request, the value of this parameter is derived from the Result parameter of the RT-OPEN response primitive.

8.1.1.2.2

Use of the other A-RELEASE response and confirm primitive parameters Result is "affirmative".

8.1.1.2.2.1

The value of this parameter 8.1.1.3 8.1.1.3.1

Association-provider-abort Use of the ,A-P-ABORT primitive Parameter% indication primitive

b)

The use of the A-P-ABORT indication parameters are defined in IS0 8649. 8.1.1.4 Association-recovery

procedure

8.1.1.1.4.3 Quality of Service This parameter has (he same value as in the AASSOCIATE request and indication primitives. 8.1.1.1.4.4 Session requirements

The association-recovery procedure takes place concurrently with the underlying ACSE association establishment. 8.1.1.4.1 Parameters from RT-OPEN service

This parameter has the same value as in the AASSOCIATE request and indication primitives. 8.1.1.1.4.5 Initial assignment is not used. identifier of tokens

The following parameters of the RT-0,PEN service primitives are stored by the RTPMs, and mapped directly onto the corresponding parameters of the A-ASSOCIATE service primitives: al b) cl d) e) fl gl hl il il k) 1) Mode Application Context Name

I

This parameter 8.1.1.1.4.6

S.ession connection

Calling AP Title Calling AP Invocation-identifier Calling AE Qualifier Calling AE Invocation-identifier Called APTitle Called AP Invocation-identifier Called AE Qualifier Called AE Invocation-identifier Responding Responding AP Title AP Invocation-identifier AE Qualifier AE Invocation-identifier Address Address Address List

This parameter has the same value as in the AASSOCIATE indication primitive. The Calling SS-User Reference value of the A-ASSOCIATE indication primitive is returned as Called SSUser Reference by the association-responding RTPM. 8.1.1.2 Association-release the procedure

The association-release concurrently with association release. 8.1.1.2.1 Directly

procedure takes place underlying ACSE

mapped

parameters

ml Responding nl 0) Pl ql r) Responding

The following parameters of the RT-CLOSE service primitives are mapped directly onto the corresponding parameters of the A-RELEASE service primitives: al b) Reason User-data (on user information).

Calling Presentation Called Presentation Responding

Presentation

PresentationContext

Definition
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sl tl ul 8.1.1.4.2

Presentation List

Context

Definition Context Name Context Result

Result

8.1.1.4.5

Default Presentation Default Presentation Parameters

Use of the other A-ASSOCIATE response and confirm primitive parameters Initial assignment of tokens

8.1.1.4.5.1

not used A-ASSOCIATE

The following parameters of the service primitives are not used: a) b) Presentation requirements

Initial synchronization number. Parameters used association-establishment procedure

point

serial

If the value of this parameter in the AASSOCIATE indication primitive was "acceptor chooses", the association-responding RTPM will either keep (value "acceptor side") or return (value "requestor side") the tokens depending upon whether it had them before the session-connection was aborted. 8.1.1.4.5.2 Result

8.1.1.4.3

as

in

the

The following parameters of the A-ASSOCIATE service primitives are used as described for the (see association-establishment procedure 8.1.1.1): a) b) cl d) 8.1.1.4.4 User Information Quality of Service Session requirements Session connection identifier.

If the association-responding RTPM rejects the application-association, the value of this parameter is set to either "rejected (transient)" or "rejected (permanent)", else it is set to "accepted". 8.1.1.5 Association-abort, providerlabort and user-abort procedures Use of the A-ABORT request indication primitive parameters Abort source and

8.1.1.5.1

8.1.1.5.1.1

This parameter 8.1.1.5.1.2

value is "ACSE service-user".

User information value is the RTAB APDC. services in

Use of the other A-ASSOCIATE request and indication primitive parameters. Initial assignment rules apply: it specifies RTPM has the the value "requestor of tokens

This parameter 8.1.2 8.1.2;1

8.1.1.4.4.1

Mapping on the ACSE X.410-1984 mode Association-establishment procedure

The following Turn, side". bl

a) If the association-initiating

If the association-initiating RTPM does not have the Turn, but has issued a PCONTROL-GIVE request primitive with no confirmation that the tokens were received, it specifies the value "acceptor side". (Receipt of data serves as confirmation that the tokens were received.) If the association-initiating RTPM does not have the tokens and does not have an P-CONTROL-GIVE request primitive outstanding, it specifies the value "acceptor chooses".

The association-establishment procedure place concurrently with the underlying association establishment. 8.1.2.1.1 Directly mapped parameters

takes ACSE

The following parameters of the RT-OPEN service primitives are mapped directly onto the corresponding parameters of the A-ASSOCIATE service primitives: a) b) cl Mode Result Source Diagnostic

cl
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d) e) f) 8.1.2.1.2

Calling Called

Presentation Presentation

Address Address Address

8.1.2.2

Association-release

procedure

Responding

Presentation not used

The association-release concurrently with association release.
8.1.2.2.1 Parameters

the

procedure takes place underlying ACSE

Parameters

not used A-RELEASE

The following parameters of the service primitives are not used:

A-ASSOCIATE

The following parameters of the service primitives are not used: al bl 8.1.2.3 Reason User Information Association-provider-abort Procedure of the A-P-ABORT primitive parameters

a) Application b) Calling
Cl d) el f) g) hl il jl kl 11 ml nl 01 Calling Calling Calling Called Called Called Called

Context

Name

AP Title AP Invocation-identifier AE'Qualifier AE Invocation-identifier AP Title AP Invocation-identifier AE Qualifier AE Invocation-identifier AP Title AP Invocation-identifier AE Qualifier AE Invocation-identifier Context Context Definition Definition List Result

8.1.2.3.1 Use

indication

The use of the A-P-ABORT indication parameters are defined in IS0 8649. 8.1.2.4 Association-recovery

primitive

procedure

Responding Responding Responding Responding Presentaticn? Presentation List Default Default

The association-recovery procedure takes place concurrently with the underlying ACSE association establishment.
8.1.2.4.1 Parameters

from RT-OPEN

service service mapped of the

The following parameters of the RT-OPEN primitives are stored by the RTP%ls, and directly onto the corresponding parameters A-ASSOCIATE service primitives: a1 b) cl d) Mode Calling Called Presentation Presentation Address Address Address.

Pl 91

Presentation Presentation

Context Context

Name Result

8.1.2.1.3 Parameters

used as in normal mode

The following parameters of the A-ASSOCIATE service primitives are used as in the normal mode (see 8.1.1) : a) `b) cl d) e) fJ User Result Quality Session Initial Session of Service Requirements Assignment Connection ofTokens Identifier. Information

Responding

Presentation not used

8.1.2.4.2 Parameters

The following parameters of the service primitives are not used: a) b) c) d) Application Calling Calling Calling Context Name

A-ASSOCIATE

AP Title AP Invocation-identifier AE Qualifier
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e)

Calling

AE Invocation-identifier

8.1.2.4.3 Parameters

used as in normal mode

f)

Called AP Title Called AP Invocation-identifier

d
i)
j) ~:

The following parameters of the A-ASSOCIATE service primitives are used as in the normal mode (see 8.1.1) : a) bl cl d) e) f) Result 8.1.2.5 8.1.2.5.1 List Association-abort, provider-abort and user-abort procedures Parameters not used A-ABORT User information Result Quality Session Initial Session of Service requirements assignment connection of tokens identifier.

h) Called AE Qualifier
Called AE Invocation-identifier Responding Responding Responding AP Title AP Invocation-identifier AE Qualifier AE Invocation-identifier Context Context Definition Definition Context Context Name Result

kl 11

ml Responding nl 01 Pl 91 r)
S)

Presentation Presentation List

Default Presentation Default Presentation Presentation

The following parameters of the service primitives are not used: al Abort Source. Serial 8.1.2.5.2 Parameters

Requirements Point

Initial Synchronization Number.

used as in normal mode

The following parameters of the A-ASSOCIATE service primitives are used as in the normal mode (see 8.1.11: a1 User information.
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8.2

Mapping

on the presentation

services

This subclause defines how the presentation service primitives described in IS0 8822 are used by the RTPM. Table 9 defines the mapping of the RTSE service primitives and APDUs on the presentation service primitives. This subclause defines the mapping onto presentation services in both normal mode and in X.410-1984 mode. 8.2.1 8.2.1.1 Transfer procedure

Use of the P-ACTIVITY-START request and indication primitive parameters

The property required of activity identifiers is that they should uniquely identify an activity during a reasonable time interval within a particular session-connection, so that duplicates can be detected in the face of error situations. These identifiers are allocated by numbering the activities during a session, starting with one for the first and incrementing for each successive activity, and to represent the number by a data element of type INTEGER, encoded according to IS0 8825. It' is unnecessary for the receiving RTPM to make assumptions on the allocation method, only to be able to compare two identifiers for equality, octet by octet. 8.2.1.1.2 User data is not used. and

8.2.1.1.1 Activity identifier The activity identifier identifies the activity by means of a serial number. The first activity started ,on the session-connection is assigned the number 1. Each successive activity for that direction of transfer is assigned the next number. Thus numbering is separate for each direction of transfer.

This parameter 8.2.1.2 8.2.1.2.1

Use of the P-DATA request indication primitive parameters User data

The maximum user data size (number of octets of the RTTR APDU value) will have been negotiated during the association-establishment procedure. The sending RTPM shall submit user data that conforms to that agreement.

Table

9 - Presentation

mapping

overview

RTSE service RT-TRAMFER req

APDU

Presentation-service P-ACTIVITY-START req/ ind P-DATA reql ind P-,MINOR-SYNCHRONIZE req/ind/resp/conf P-ACTIVITY-END req/ind/resp/conf P-TOKEN-PLEASE req/ind P-CO?jTROL-GIVE req/ind P-U-EXCEPTION-REPORT req/ind P-P-EXCEPTION-REPORT ind P-ACTIVITY-INTERRUPT req/ind/resp/conf P-ACTIVITY-DISCARD req/ind/resp/conf P-ACTIVITY-RESUME req/ind

RTTR RT-TRANSFER ind/conf RT-TURN-PLEASE req/ind RT-TURN-GIVE req/ind user-exception-report provider-exception-report transfer-interrupt transfer-discard transfer-resumption

RTTP

req
ind resp conf

request indication response confirm.
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8.2.1.3

Use of the P-MINOR-SYNCHRONIZE service parameters Type

8.2.2.1.2

User data

This is the RTTP APDU. 8.2.3 8.2.3.1 Turn-give procedure Use of the P-CONTROL-GIVE service parameters

8.2.1.3.1

The RTPM uses only the "explicit confirmation expected," type of minor synchronization. 8.2.1.3.2 Synchronization number point serial

The session service-provider allocates checkpoint serial numbers and passes them to the sending and receiving RTPMs to associate with the transmitted data. 8.2.1.3.3 User data is not used

The P-CONTROL-GIVE service primitives have no parameters. The data, minor synchronize, and major/activity tokens are automatically passed to the other RTPiM. 8.2.4 8.2.4-l User-exception-report procedure service

Use of the P-U-EXCEPTION-REPORT parameters Reason

This parameter 8.2.1.4 8.2.1.4.1

8.2.4.1.1

Use of the P-ACTIVITY-END service parameters Synchronization number point serial

This parameter reasons: a) b) c) d) e) 8.2.4.1.2 receiving

may specify one of the following ability jeopardized;

local SS-User error; sequence error; unrecoverable non-specific procedure error; error.

The serial number of the implied major synchronization point is allocated by the session service-provider and passed up to both RTPIvIs. 8.2.1.4.2 User da@ is not used. procedure

This parameter 8.2.2 8.2.2.1

User data is not used.

Turn-please

This parameter 8.2.5 8.2.5-l

Use' of the P-TOKEN-PLEASE request and indication primitive parameters Tokens

Provider-exception-report procedure Use of the P-P-EXCEPTION-REPORT parameters Reasdn following reason codes shall be service

8.2.2.1.1

The receiving RTPM shall only request the data token. Since the tokens cannot be separated, the sending RTPM always surrenders all-of the other when issuing available tokens the P-CONTROLiGIVE request primitive.

8.2.5.1.1

One of the supplied: a) b)

protocol error; non-specific error.

IS 13707 (Part2) IS0 / IEC 9066-2
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8.2.6 8.2.6.1

Transfer-interrupt

procedure service

8.2.8.1.2

Old activity identifier

Use of the P-ACTIVITY-INTERRUPT parameters Reason

8.2.6.1.1

The sending RTPM shall supply the original activity identifier which was assigned to the previously interrupted activity in the PACTIVITY-START request primitive. 8.2.8.1.3 Synchronization number point serial

This parameter a) b) 8.2.7 8.2.7.1 8.2.7.1.1

may specify one of the following:

local SS-User error; non-specific error. procetiure

Transfer-discard

Use of the P-ACTIVITY-DISCARD service parameters Reason may specify one of the following:

This parameter al bl

local SS-User error; unrecoverable non-specific procedure error; error. procedure

The sending RTPM will specify the serial number of the last confirmed checkpoint in the interrupted activity. The session service-provider will also set the current session serial number to this value. If there was no previously confirmed checkpoint, the activity cannot be continued. The sending RTPM sha.11 then send an P-ACTIVITY-RESUME request primitive (with the synchronization point serial number set to zero), followed by an PACTIVITY-DISCARD request primitive. 8.2.8.1.4 Old session connection identifier

cl
8.2.8 8.2.8. 1

Transfer-resumption

Use of the P-ACTIVITY-RESUME service parameters Activity identifier

8.2.8. 1.1

The s ending RTPM shall allocate and supply the next activity identifier number for the current session.

The sending RTPM may supply the session connection identifier of the session-connection during which the activity was started; it shall supply it if that session-connection is not the current one. This session connection identifier is conveyed in the Calling SS-User Reference; Common Reference, and, optionally, Additional Reference information components of this parameter. The Called SS-user reference component is not used. 8.2.8.1.5 User data is not used.

This parameter
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9

Abstract

Syntax Definition

of APDUs

The abstract syntax of each RTSE APDU 1s specified in this clause using the abstract syntax notation of IS0 8824, and is shown in figure 1.

Reliable-Transfer-APDUs BEGIN

Cjoint-iso-ccitt reliable-transfer

(3) apdus (0)) DEFINITIONS

:: =

EXPORTS rTSE, rTSE-abstract-syntax, RTORQapdu, RTOACapdu, RTORJapdu, RTABapdu; -IMPORTS APPLICATION-SERVICE-ELEMENT rTSE-abstract-syntax FROM

for use by Presentation

Layer only
{ join;-iso-c&t (2))

Remote-Operations-Notation-extension remote-operations(4)

notation-extension(Z)}; (3) abstract-syntax (3) aselD (1))

OBJECT IDENTIFIER

:: = { joint-iso-ccitt reliable-transfer :: = Cjoint-iso-ccitt reliable-transfer

rTSE APPLICATION-SERVICE-ELEMENT RTSE-apdus:: = CHOICE { rtorq-apdu rtoac-apdu rtorj-apdu rttp-apdu rttr-apdu rtab-apdu

[16] IMPLICIT [17] IMPLICIT 1181 IMPLICIT

RTORQapdu, RTOACapdu, RTORJ apdu, RTTPapdu, RTTRapdu,

[22] IMPLICIT

RTABapdu 1

-_ Tags [191, [201, [21]are used by the values of the UNBtND macro of the RO-notation of -_ ISOIIEC 9072-l. Tags [O] to 1151 inclusive are reserved for the __ use by the APDUs ofROSE (ISOIIEC 9072-2). Any occurrence of -_ ANY in this module shall be replaced by a single ASN.1 type (ifany) in an RTSE:user __ protocol specification. In addition any RTSE-user protocol sharing a single named -_ abstract syntax with the RTSEprotocol shall use distinct tags for the single -_ presentation data values in the user data parameters of the RT.-CLOSE (if any) and -- RT-TRANSFER services. These tags shall be distinct from the tag values 1161, Cl 71, -- 1181 and 1221 and from the ASN.1 types INTEGER and OCTET STRING. __ Note: The above conditions are ensured, if the RTSE-user protocol specification uses the -- RO-notation of ISOIIEC 9072-l.

__ In X.410-1984 mode only the components of RTORQapdu, RTOACapdu, RTORJapdu __ and RTABapdu are used by the presentation layer. This has the effect that the following __ APDU types appear in the protocol in X.410-1984 mode instead of the alternative types -_ of the RTSE-apdus type: __ RTORQapdu -_ RTOACapdu __ RTORJapdu __ RTTPapdu __ RTTRapdu __ R TABapdu -- RTSE Protocol continued

Figure 1 (Part 1 of 3) - Abstract

syntax specik

tion of RTSE protocol
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-- RTSE

Protocol continued :: =
SET { IO] IMPLICIT INTEGER DEFAULT 0, [l] IMPLICIT INTEGER DEFAULT 3, [2] IMPLICIT INTEGER {monologue(O), 13) ConnectionData, [4] IMPLICIT INTEGER OPTIONAL SET ( [0] IMPLICIT INiEGER DEFAULT 0, [l] IMPL!CIT INTEGER DEFAULT 3, _ (21 ConnectionData} SET{ [O] IMPLICIT RefuseReason OPTIONAL,-111ANY OPTIONAL --twa(l)} DEFAULT monologue,

RTORQapdu

checkpointsize windowSize dialogueMode ConnectionDataRQ applicationProtocol RTOACapdu

solely inX.410-1984

mode--}

:: =

checkpointSize windowsize ConnectionDataAC RTORJapdu

:: =

refuseReason userDataRJ RTTPapdu RTTRapdu

RTSE

only in X.410-1984 mode user data, only in normal mode--)

: : = --priority :: =
:: =

--

INTEGER OCTET STRING SET { [O] IMPLICIT AbortReason OPTIONAL, [l] IMPLICIT BIT STRING OPTIONAL, --

RTABapdu

abortReason reflectedparameter userdataAB

8 bits maximum,

12) ANY OPTIONAL --

only if abortReason is invalidparameter only in normal mode and if abortReason __ is userError--)

-- RTSE

Protocol continued

Figure

1 (Part 2 of 3)

- Abstract

syntax specification

of RTSE protocol
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- RTSE Protocol continued
ConnectionData open

:: =

CHOICE ( IO] ANY, --

RTSE user data -- this alternative is encoded as [Ol IMPLICIT NULL __ in the case of absence of RTSE user data,

recover

[l] IMPLICIT SessionConnectionldentifier}

SessionConnectionldentifier

:: = SEQUENCE { CallingSSuserReference, CommonReference, [O] IMPLICIT AdditionalReferencelnformation INTEGER { t-tsBusy(O), cannotRecover( validationFailure(2). unacceptableDialogueMode(3)) OPTIONAL}

RefuseReason :: =

CallingSSuserReference

:: =

CHOICE{ T61 String OCTET STRING UTCTime

_- solely --

in X.410-1984 mode --, solely in normal mode -- )

CommonReference

:: =

AdditionalReferencelnformation

:: =

T61String

AbortReason

:: =

INTEGER ( localSystemProblem(0). invalidParameter( --

reflectedparameter

supplied

unrecognizedActivity(2). temporaryProblem(3). __ the RTSE cannbt protocolErrqr(4). --

accept a session for a period of time -RTSE level protocol error -permanentProblem (5). --provider-abort solely in normal mode -userError (6). -- user-abort solely in normal mode -transfercompleted (7) --activity can P be discarded --)

END

--

of RTSE Protocol

Figure

1 (Part 3 of 3)

- Abstract

syntax

specification

of RTSE protocol
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10

Conformance

10.2

Static requirements

An implementation claiming conformance to this part 2 of ISO/IEC 9066 shall comply with the requirements given in 10.1 to 10.3. 10.1 Statemeht requirements

The system shall conform to the abstract syntax definition of APDUs defined in clause 9. 10.3 Dynamic requirements

The system shall a) conform to the elements defined in clause 7; of procedure

An implementor shall state the application context for which conformance is claimed, including whether the system supports normal mode, X.$10-1984 mode, or both.

b) conform to the mappings to the used services, for which conformance is claimed, as defined in clause 8.
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Annex A
(normative)

RTPM State tables
A.1

General

f)

This annex defines a single Reliable Transfer Protocol Machine (RTPM) in terms of a state table. The state table shows the interrelationship between the state of an application-association, the incoming events that occur in the protocol, the actions taken, and, finally the resultant state of the application-association. The RTPM state table does not constitute a formal definition of the RTPM. It is included to provide a more precise specification of the elements of procedure defined in clause 7. This annex contains the following tables:

Table A.6 through A.16 inclusive specifies the RTPM state table us.ing the abbreviations of the above tables.

For some events the source and thk target is the RTPM ( internal event). If the RTPM issues an internal event as part of an action taken, the RTPM awaits that internal event in the resultant state.

A:2

Conventions
event (row) and a

The intersection of an incoming state (column) forms a cell.

a) Table A.1 specifies the abbreviated

name, source, and name I description of each incoming event. The sources are: 1) RTSE-user (RTSE-user); 2) peer RTPhI (RTP&I-peer); 3) Association Control Service Element (ACSE); 4) Presentation service-provider (PSprovider); and 5) RTPM (RTPM). name of each state of the RTPM.

In the state table, a blank cell represents the combination of an incoming event and a state that is not defined for the RTP,M (See A.3.1). Some states await solely some incoming events from the source RTPM (internal events). These states are marked by * and no other incoming events are considered. A non-blank cell represents an incoming event and a state that-is defined for the RTPM. Subh a cell contains one or more action lists. An action list may be either mandatory or,conditional. If a cell contains a mandatory action list, it is the only action list in the cell. A mandatory action list contains: a) b) c) optionally optionally and one or more outgoing, events, one or more specific actions,

b) Table A.2 specifies the abbreviated cl Table A.3 specifies the abbreviated

name, target, and name I description of each outgoing event. The targets are: 1) RTSE-user (RTSE-user); 2) peer RTPM (RTPM-peer); 3) Association Control Service Element (ACSE); 4) Presentation service-provider (PSprovider); and 5) RTPM (RTPM). Table A.4 specifies the predicates. Table A.5 specifies the specific actions.

a resultant state. action list contains:

A conditional

a) a predicate

d)

e)

expression comprising predicates and Boolean operators (1 represents the Boolean NOT, &,reprksents the Boolean AND 1, and a mandatory action list (this mandatory action list is used only' if the predicate expression is true),

36

IS 13307 ( Part 2 1: 1993

IS0 / IEC 9066-2 `:1989

A local collision between an incoming event from the RTSE-user and the. association-recovery procedure is modeled by deferring that event until completion of the association-recovery procedure.

This boolean variable is set TRUE if the RTPM is the association-initiating RTPM (specific action [all), else set FALSE (specific action [a2]). This boolean pll. A.4.2 variable is tested in the predicate

A.3

Actions to.be taken by the RTPM

The RTPM state table defines the action to be taken by the RTPM in terms of an optional outgoing event, optional specific actions, and the resultant state of the application-association. A.3.1 Invalid intersections

Checkpoint-confirmed

Blank cells indicate an invalid intersection of an incoming event and state. If such an intersection occurs, one of the following actions shall be taken:

This boolean variable is TRUE, if at least' one checkpoint was confirmed during the transfer procedure. It is set FALSE at the beginning of the transfer procedure (specific action la301 and Ea331). It is set TRUE,. if a, P-MINORSYNCHRONIZE confirm primitive is issued to the sending RTPM (specific action [a321). A-4.3 Outstanding-minor-syncs

a) If the incoming

event comes from the RTSE-user, or is an internal event, any action taken by the RTPM is a local matter.

b)

If the incoming event is related to a received APDU, PS-provider, or ACSE: either the RTPM issues an an appropriate internal event, or the RTPM issues both an RT-PAind outgoing event ( to its RTSEuser) and an RTAB outgoing event (to its peer RTPM). Valid intersections

This integer variable indicates the number of outstanding checkpoint confirmations during the transfer procedure. It is set to zero at the beginning of the transfer procedure (specific action la301 and la331). It is incremented by one, if a P-MI1;OR-SYNCHRONIZE request primitive is issued by the sending RTPM (specific action la311). It is decremented by 1, if a P-MIKORSYNCHRONIZE `confirm primitive is issued to the sending RTPM (specific action [a32]). The value of this variable is compared .with `the value of the window-size field of the RTOAC APDU in the predicate ~32. The value of this variable is compared .with. the value zero in the predicate ~33. A.4.4 Transfer timer tr

A.3.2

If the intersection of the state and incoming event is valid, one of the following actions shall be taken: a) b) If the cell contains a mandatory action list, the RTPM takes the actions specified. If a cell contains one or more conditional action lists, for each predicate expression that is true, the RTPM takes the actions specified. If none of the predicate expressions are true, the RTPM takes one of the actions defined in A.3.1.

This timer is used to control the transfer time. It is set to the value of the transfer-time parameter of the RT-TRANSFER request primitive (specific action [a30]). It is reset if a RT-TRANSFER response primitive is issued by the sending RTPM. (specific action la351). In the case of time out the internal timeout occurs. A.4.5 Recovery timer ret event tr-

A.4

Definition of variables timers

and

The fo,llowing variables A.4.1

and timers are specified. RTPM

Association-initiating

.This timer is used to control the recovery time. It is set to a locally specified value in the recovery case (specific action la381). It is reset after successful recovery (specific action [a39]). In the case of time out the internal timeout occurs. event rec-
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Table

A.1 (Part

1 of 3)

-Incoming event list

Abbreviated name RT-OPreq RT-OPres RT-OPresRT-CLreq RT-CLres RT-TRreq RT-TPreq RT-TGreq RT-UAreq RTORQ RTOAC RTORJ RTAB RTTR RTTP +

Source

Name and description

RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTPM-peer RTPM-peer RTPM-peer RTPM-peer RTPM-peer RTPM-peer

RT-OPEN RT-OPEN RT-OPEN RT'-CLOSE RT-CLOSE

request primitive response primitive response primitive request primitive response primitive request primitive request primitive request primitive request primitive (Result = "accepted")

(Result, = "rejected")

RT-TRANSFER RT-TURN-PLEASE RT-TURN-GIVE RT-U-ABORT

RTORQ APDU as user data of an A-ASSOCIATE indication primitive RTOAC APDC as user data of an A-ASSOCIATE confirm primitive RTORJ APDU as user data of an A-ASSOCIATE confirm primitive RTAB APDU as user data of an A-ABORT primitive RTTR APDU as user data of a P-DATA primitive P-TOKEN-PLEASE indication primitive with RTTP APDU as user data indication

indication optionally
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Table

A.1 (Part 2 of 3)

-Incoming event list

Abbreviated name A-ASCcnfA-RELind A-RELcnf A-PABind P-ASind P-MSind P-MScnf P-AEind P-AEcnf P-CGind P-UEind P-PEind P-AIind P-AIcnf P-ADind P-ADcnf P-ARina

Source

Name and description

ACSE ACSE ACSE ACSE PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider

A-ASSOCIATE confirm primitive no RTORJ APDU A-RELEASE A-RELEASE indication primitive

(Result = "rejected")

confirm primitive primitive indication primitive primitive

A-P-ABORT indication P-ACTIVITY-START

P-MINOR-SYNCHRONIZE P-MINOR-SYNCHRONIZE P-ACTIVITY-END P-ACTIVITY-END P-CONTROL-GIVE indication

indication

confirm primitive primitive

confirm primitive indication primitive indication indication indication primitive primitive primitive

P-U-EXCEPTION-REPORT P-P-EXCEPTION-REPORT P-ACTIVITY-INTERRUPT P-ACTIVITY-INTERRUPT P-ACTIVITY-DISCARD P-ACTIVITY-DISCARD P-ACTIVITY-RESUME

confirm primitive indication primitive

confirm primitive indication pritiitive
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Table

A.1 (Part 3 of 3)

- Incoming

event

list

Abbkeviated name a-ab a-res a-ret ass-ab ass-ret ass-ret-neg next p-ab r-problem-l r-problem-2 ret-timeout rt-ab s-problem- 1 s-problem-Z s-problem-3 tr-discard tr-interr tr-p-ab tr-pos tr-res tr-timeout transfer u-exr

Source

Name and description

RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM

association

aborted, recover by the receiving RTPM

activity resumption activity completed,

discarded, or interrupted procedure procedure

start of association-abort start of association-recovery association-recovery

unsuccessful

transfer of RTTR APDU start of provider-abort receiving receiving procedure

RTPM problem RTPM problem more severe than r-problem-l

recovery time out RTAB receive'd sending RTPM problem .

sending RTPM problem more severe than s-problem-l sending RTPM problem more severe than s-problem-2 start of transfer-discard start of transfer-interrupt start of procedures abort procedure procedure followed by provider-

transfer-abort

RTPM RTPM RTPM RTPM RTPM

transfer successful completed start of transfer-resumption transfer time out start of transfer or transfer-retry start of user-exception-report procedures procedure

procedure
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Table A.2 (Part 1 of 2) - RTPM states

Abbrkiated name STA0 STAOl STAOB STAll STAl2 STAB1 STA22 STA30 STA3 1 STA32 STA321* STA34 * STA341 STA35 * STA35 1 STA36 * STA362

Name and description

idle; unassociated awaiting RTOAC, RTORJ, or A-ASCcnfawaiting RT-OPres + , or RT-OPrbsassociated; RTPM is association-initiating RTPM and sending RTPM associated; RTPM is association-initiating RTPM and receiving RTPM associated, RTPM is association- responding RTPM and sending RTPM associated,RTPM is association-responding RTPM and receiving RTPM transfer; sending RTPM suspended transfer; sending RTPM awaiting P-AEcnf; sending RTPM awaiting tr-pos; sending RTPM awaiting k-discard to be followedby RT-TRcnf + ; sending RTPM awaiting P-ADcnf to be followed by RT-TRcnf + ; sending RTPM awaiting tr-discard to be followed by RT-TRcnf-; sending RTPM awaiting P-ADcnf to be,followed by RT-TRcnf-; sending RTP-M awaiting tr-discard to be followed by transfer-retry procedure; sending RTPM awaiting P-ADcnf to be followed by transfer-retry procedure; sending RTPM awaiting tr-interr to be followed by transfer-retry procedure; sending RTPM awaiting P-Alcnf; sending RTPM awaiting tr-res; sending RTPM awaiting ass-ab; sending RTPM a@aiting a-ab; transfer sending RTPM awaiting rt-ab; transfer sending RTPM awaiting RTTR ; transfer receiving RTPM awaiting RTTR ; ignored transfer receiving RTPM

STA37 * STA37 1 STA372 * STA38 * STA381* STA39 * STA40 STAQOO
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Table A.2 (Part 2 of 21- RTPM states

Abbreviated name !$TA41 STA410 STA42 STA43 * STA44 * STA45 * STA48 * STA481* STA49 * STA51*

Name and description

awaiting awaiting

P-MSind or P-AEind;

transfer receiving

RTPM RTPM

P-MSind or P-AEind; ignored transfer receiving

awaiting recovery after u-exr event; transfer receiving awaiting a-ret; transfer receiving RTPM awaiting u-exr; transfer receiving awaiting a-res; transfer receiving awaiting ass-ab; transfer receiving RTPM RTPM RTPM

RTPNl

awaiting a-ab; transfer receiving awaiting rt-ab; transfer receiving awaiting ass-ret or ass-ret-neg; activity

RTPM RTPM procedure outside

association-recovery

STA510 `STA52 STA53 * STA53 1

awaiting RTOAC or RTORJ; association-recovery activity awaiting RTORQ; association-recovery awaiting ass-ret or ass-ret-neg; RTPM awaiting RTPM

procedure outside

procedure outside activity procedure sending

association-recovery

RTOAC or RTORJ; association-recovery

procedure sending

STA532 STA54 *

awaiting RTORQ; association-recovery awaiting ass-ret or ass-ret-neg; RTPM

procedure sending RTPM procedure procedure receiving

association-recovery

STA541

awaiting RTOAC or RTORJ; association-recovery RTPM awaiting RTORQ; association-recovery awaiting abort; unassociated awaiting abort'; assckiated awaiting rt-ab outside transfer awaiting RT-CLres awaiting A-RELcnf

receiving

STA542 STA70 * STA71* STA72 * STA91 STA92

procedure receiving

RTPM
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Table A.3 (Part 1 of 3) - Outgoing event list

Abbreviated name RT-OPind RT-OPcnf + RT-OPcnfRT-CLind RT-C Lcnf RT-TRind RT-TPind RT-TRcnf +

Target

Name and description

RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTSE-user RTPM-peer RTPM-peer

RT-OPEN indication primitive RT-OPEN confirm primitive RT-OPEN confirm primitive RT-CLOSE (Result = "accepted") (Result = "rejected")

indication primitive

RT-CLOSE confirm primitive RT-TRANSFER indication primitive primitive

RT-TURN-PLEASE

indication

RT-TRANSFER confirm primitive (Result = "APDU-transferred") RT-TRANSFER confirm primitive (Result = "APDU-not-transferred") RT-TURN-GIVE RT-U-ABORT RT-P-ABORT indication primitive indication primitive

RT-TRcnfRT-TGind RT-UAind RT-PAind RTORQ RTOAC

indication primitive

RTORQ APDU as user data of an A-ASSOCIATE request primitive RTOAC APDU as user data of an A-ASSOCIATE response primitive RTORJ APDU as user data of an A-ASSOCIATE response primitive RTAB APDC as user data of an A-ABORT primitive request

RTORJ RTAB RTTR

RTPM-peer

RTPM-peer RTPM-peer

RTTR APDU as user data of a P-DATA request primitive P-TOKEN-PLEASE indication primitive with RTTP APDU as user data optionally

RTTP

RTPM-peer
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Table A.3 (Part 2 of 3) -Outgoing event list

Abbreviated name A-RELreq A-RELres P-ASreq P-MSreq P-MSres P-AEreq P-AEres P-CGreq P-UEreq P-AIreq P-A'Ires P-ADreq P-ADres P-ARreq

Source

Name and description

ACSE ACSE PS-provider PS-provider PS-provider PS-provider P&provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider PS-provider

A-RELEASE A-RELEASE

request primitive response primitive
request primitive

P-ACTIVITY-START

P-MINOR-SYNCHRONIZE P-MINOR-SYNCHRONIZE P-ACTIVITY-END P-ACTIVITY-END P-CONTROL-GIVE

request primitive response primitive

request primitive response primitive request primitive request primitive request primitive response primitive request response primitive primitive

P-C'-EXCEPTION-REPORT P-ACTIVITY-INTERRUPT P-ACTIVITY-INTERRUPT P-ACTIVITY-DISCARD P-ACTIVITY-DISCARD P-ACTIVITY-RESUME

request primitive
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Table

A.3 (Part 3 of 3)

- Outgoing event list

Abbreviated name a-ab ares a-ret ass-ab ass-ret ass-ret-neg next p-ab rt-ab tr-discard tr-interr tr-p-ab tr-pos tr-res transfer u-exr

Source

Name and description

RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM RTPM

association

aborted, recover by the receiving RTPM

activity resumption activity completed,

discarded, or interrupted procedure procedure

start of association-abort start of association-recovery association-recovery

unsuccessful

transfer of RTTR APDL' start of provider-abort RTAB received start of transfer-discard start of transfer-interrupt start of procedures abort procedure procedure followed by providerprocedure

transfer-abort

transfer successful completed start of transfer-resumption procedure procedures

start of transfer or transfer-retry &art of user-exception-report

procedure
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Table A.4 : Predicates

Code
Pl P2 P5 ~6 PI1 P36

I

Name and description
RTPM can support the requested application-association

Turn

assigned

to RTPM association-recovery of association-recovery RTPM to transfer the encoded-APDU-value (no

RTPM can support 1 transient rejection

association-initiating

only one RTTR APDC' required checkpointing) RTTR APDU APDC-value

P31

is the last one in a series

of RTTR APDL's to transfer

the encoded

~32 p33 p34 P35 ~361 ~362 ~363 ~364 ~365 P41 P43 P44 P45 ~46 P91 P92 P93

outstanding-mmor-syncs outstanding-minor-syncs sending RTPM is willing

< window-size = 0 to recover from P-PEind received) ability jeopardized" procedure error" error" error" error"

checkpoint-confirmed reason reason reason reason reason received transfer receiving receiving receiving parameter parameter parameter parameter parameter value value value value value

(at least on P-NIScnf of P-UEind of P-UEind of P-UEind of P-UEind of P-LEind

is "receiving

is "unrecoverable is "non-specific is "sequence

is "local SS-user

RTTR secured to be resumed was already to perform completed and ignore transfer

RTP,M is willing RTPM RTPM can resume is willing

the activity to perform the association-abort procedure

RTAB abort-reason RTAB abort-reason RTAB abort-reason

field value field value

is "user-error" is "permanent-error" is "transfer-completed"

field id value
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Table A.5 -Specific

actions

Code
I

Name and description
association-initiating association-initiating

al a2
a30

RTPM = TRUE. RTPM = FALSE.

outstanding-minor-syncs = 0, set timer tr to transfer-time, checkpoint-confirmed = FALSE. outstanding-minor-syncs outstanding-minor-syncs checkpoint-confirmed outstanding-minor-syncs reset timer tr. ret to local recovery rec. parameter value of P-UEreq to "sequence error". time. = outstanding-minor-syncs = outstanding-minor-syncs = TRUE. = 0. + 1. - 1,

a31 a32

a33 a35 a38 a39 a41

set timer reset timer

set reason
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Table A.6 - RTPM state table: association-establishment

STAO RT-OPreq pl: RTORQ fall STAOl pl: RT-OPind

STAOl

STAOP

RTORQ

Ml
STAOB `pl: RTORJ STAO RT-OPres + p2: RTOAC STA21 1 p2: RTOAC STA22 RT-OPresp2: RT-OPcnf + STAll `p2: RT-OPcnf + STA12 RTORJ A-ASCcnfRT-OPcnfSTAO RT-OPcnfSTAO RT-PAind STAO RT-PAind STAO RTORJ STAO

RTOAC

A-PABind
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Table A.7 - RTPM

state table: association

established,

outside

transfer

I
RT-TRreq P-ASind P-AIind

STAll

~STA12

STAB1
transfer STA30

STA22

transfer STA30 STA40 P-Aires STAl2

STA40 P-Ah-es STA22

[a391
a-res STA45 ass-ab STA48 RTTP STA12 RT-TPind STA21 RT-TGreq P-CGind RT-CLreq A-RELind A-RELreq STA92 P-CGreq STAl2 RT-TGind STAll P-CGreq STA22

La391
a-res STA45 ass-ab STA48 RTTP STA22

RT-TGind STAB 1

RT-C Lind STA91 ass-ret STA51 RTAB STAO rt-ab STA72 ass-ret STA5 1 RTAB STAO rt-ab STA72 p-ab STA71 ass-ret STA52 RTAB STAO rt-ab STA72 ass-ret STA52 RTAB STAO rt-ab STA72 p-ab STA71

A-PABind

RT-UAreq RTAB

ret-timeout
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Tabir A.8 (Part 1 of 3) - RTPM state table: sending RTPM, transfer

STA30

STA31

STA32

STA321*

ransfer

p30: [a301

P- ASreq

RTTR P-AEreq STA32 7 p30: [a301 P-ASreq next STASO. lext @32& 7~31: RTTR P-MSreq [a311 next STA30 ~328~~31: RTTR P-AEreq STA32 7~32: STA31 P-MScnf [a321 STA30 [a321 next STASO [a321 STA32 p33: tr-pos STA32 1
pll:

?-AEcnf

;r-pos

[a351 RT-TRcnf + STAll 1pll: [a351 RT-TRcnf + STAB1

tr-timeout

tr-discard [a381 STA35

tr-discard [a381 STA35

tr-discard [a381 STA35
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Table A.8 (Part 2 of 3)

- RTPM state table: sending RTPM, transfer

I
P-UEind

STA30

I STA31

I STA32

~361: tr-p-ab STA7 1 ~362: tr-discard STA36 ~363: k-discard STA35 ~364: tr-discard STA34 p365&p35: tr-interr STA37 ~3658~ 7 ~35: tr-discard STA36

~361: tr-p-ab STA71 ~362: tr-discard STA36 ~363: tr-discard STA35 ~364: tr-discard ~STA34 p365&p35: tr-interr STA37 ~3658~ 1~35: tr-discard STA36 p34&p35: tr-interr STA37 p34& 7 p35: tr-discard STA36 1 p34: tr-p-ab STA71

~361: tr-p-ab STA7 1 ~362: tr-discard STA36 ~363: tr-discard STA35 ~364: tr-discard STA34 p3658zp35: tr-interr STA37 p365& -, ~35: tr-discard STA36 p348Lp35: tr-interr STA37 p34& 7 p35: tr-discard STA36 1 p34: tr-p-ab STA7 1

P-PEind

p34&p35: tr-interr STA37 p34& 1 p35: k-discard STA36 7 p34: tr-p-ab STA7 1

51

IS 13707 ( Part 2 ) : 1993 IS0 / IEC 9066-2 :1969

Table A.6 (Part 3 of 3)

- RTPM state table: sending RTPM, transfer

I
s-problem-l

STASO

-I

STASL
I

STA32 p35: tr-interr STA37 -Jp35: tr-discard STA36 tr-discard STA36 ass-ab
I STA38

p35: tr-interr STA3'7 7p35: h-discard STA36

p35: tr-interr STA37 7 p35: tr-discard STA36 k-discard STA36 ass-ab
I STA38

s-problem-d s-problem-3 A-PABind RT-UAreq RTAB RTTP

tr-discard STA36 ass-ab STA38 a-ab STA38 1 RTAB STAO

a-ab STA381 RTAB STAO

a-ab STA381 RTAB STAO

I

rt-ab STA39

I

rt-ab STA39 RT-TPind RT-TPind I STA32

RT-TPind I STASO

I STA31
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Table A.9 - RTPM state table: sending RTPM, error handling

STA34 + tr-discard P-ADreq STA341

STA341

STA35 * P-ADreq STA35 1

STA35 1

STA36 * P-ADreq STA361

STA361

P-ADcnf

tr-pos STAS? 1

pll: [a351 RT-TRcnfSTAll 1pll: [a351 RT-TRcnfSTAZ 1

transfer STASO

A-PABind RT-UAreq RTAB

a-ab STA38 1 RTAB STAO rt-ab STA39 RT-TPind STA341 [a381 STA35 1

a-ab STA381 RTAB STAO rt-ab STA39 RT-TPind STA35 1 [a381 STA35 1 tr-p-ab STA71

a-ab STA381 RTAB STAO rt-ab STA39 RT-TPind STA361 La381 STA35 1

RTTP tr-timeout ret-timeout
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Table A.10 - RTPM state table: sending RTPM, error handling

STA37 +
r-inters ?-AIcnf :r-res P-AIreq STA37 1

STA371

STA372 *

tr-res STA372 p35: [a331 P-ARreq next STA30 7 p35: P-ARreq tr-discard STA36

A-PABind

a-ab STA381 RTAB STAO rt-ab STA39 RT-TPind STA37 1 tr-p-ab STA7 1

RT-UAreq RTAB

RTTP tr-timeout
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Table A.11

- RTPM state table: sending RTPM, error handling

STA38 *

STA381*

STA39 *

ass-ab

RTAB a-ab STA381 pll: ass-ret STA53 ypll: STA532

a-ab

rt-ab

p93 8z pll: RT-TRcnf + ass-ret STA5 1 p938z 1pll: RT-TRcnf + ass-ret STA52 p91: RT-TRcnfRT-UAind STAO p92: RT-TRcnfRT-PAind STAO 7p91& 7p92: a-ab STA381
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Table A.12

- RTPM state table: receiving

RTPM

STA40 RTTR P-MSind, STA41

STA41

S+A400 STA410

PTA410

I

STA42

p41: P-MSres STA40 RT-TRind P-AEres a-ret STA43 P-AEres a-ret STA43

P-AEind

P-hind

[a381

P-Aires a-ret STA43 P-ADind P-ADres a-ret STA43

P-Aires a-ret STA43 P-ADres a-ret STA43

[a381

[a381
P-Ah-es a-ret STA43 P-ADres a-ret STA43

[a381

P-Aires a-ret STA43 P-ADres a-ret STA43

P-Aires a-ret STA43

[a391

P-ADres a-ret STA43 STA'42

P-PEind r-problem-l

STA40 u-ekr STA44 ass-ab STA48 a-ab STA48 1 RTTP STA40 RTAB STAO rt-ab STA49

STA41 u-exr STA44 ass-ab STA48 a-ab STA48 1 RTTP STA41 RTAB STAO rt-ab STA49 -

STA400 u-exr STA44 ass-ab STA48 a-ab STA48 1 RTTP STA400 RTAB STAO rt-ab STA49

STA410 u-exr STA44 ass-ab STA48 a-ab STA481 RTTP STA410 RTAB STAO rt-ab STA49

r-problem-2 A-PABind RT-TPreq

ass-ab I STA48 a-ab I STA481

I RTAB STAO I rt-ab STA49 RT-PAind RTAB STAO

RT- WAreq
RTAB

ret-timeout
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Table A.13 (Part 1 of 2) - RTPM state table: receiving RTPM error ha'ndling

STA43 *
a-ret fill: STA12 1pll: STA22 u-exr

STA44 *

STA45 *

P-UEreq [a381 STA42

m-es

7 p43 & p45: STA40 p43 & p44 &p45: STA400 p43 & 1p44 & p45:

[a411
u-exr STA44 7p45 & 1~46: u-exr STA44 1 p45 & ~46: ass-ab STA48
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Table A.l.3 (Part 2 of 2) - RTPM state table: receiving RTPM error handling

STA48 *
tss-ab ITAB 1-ab ;TA481

STA481*

STA49 *

uab

pll: ass-ret STA54 -pll: ass-ret STA542

rt-ab

p91: RT-UAind STAO p92: RT-PAind STAO 7p91&1p92 a-ab STA48 1
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Table A.14 (Part 1 of 2) - RTPM state table: association-recovety outside transfer

STA51*
ass-ret p5: La381 RTORQ STA510 1p5: p-ab STA70 RTORQ

STA510

STA52

[a381
STA52

~58~~2: ia RTOAC STA21 p5& -J p2: [a391 RTOAC STA22 7 p5&p6: RTORJ STA52 7 p5& 7 p6: RTORJ p-ab STA70

RTOAC

p5& p2: [a391 STAll p5& 1 p2: [a391 STAl2
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Table A.14 (Part 2 of 2) - RTPM state table: association-recovery outside transfer

I
A-PABind ass-ret-neg

$TA51*
I

STAB10
I

STA52

I
p6: ass-ret STA51 7 p6: p-ab STA70

I

ass-ret-neg STA51

I

ret-timeout
. I

p-ab I STA7 1

p-ab I STA70
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Table A.15

- RTPM state table: association-recovery

during

transfer

STA53 *
ass-ret

STA53 1

STA532

STA54 * [a381 RTORQ STA54 1

STA54 1

STA542 [a381 STA542 p5& 7 p2: RTOAC
La391

RTORQ STA53 1 p58zp2:, RTOAC
tr-res

RTORQ

STA372 lp5&p6: RTORJ STA532 7~58: `~6: RTORJ tr-p-ab STA70
[a391

STA22

7 p5&p6: RTORJ STA542 -p5& -1 p6: RTORJ p-ab STA70 STA12 ass-ret-neg STA54 ass-ret-neg STA54 ass-ret-neg STA54 p6: ass-ret STA54 1 p6: p-ab STA70

0 RTOAC RTORJ A-ASCcnfA-PABind ass-ret-neg p6: ass-ret STA53 `~6: tr-p-ab STA70 tr-timeout ret-timeout tr-p-ab STA71 tr-t-es STA372 ass-ret-neg STA53 ass-ret-neg STA53 ass-ret-neg STA53

tr-p-ab STA70 p-ab STA71 p-ab STA70
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Table A.16 - RTPM state table: abort and association-release
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Annex B
(informative)

Differences between this part of ISO/IEC 9066 and CCITT Recommendation X.410 - 1984
This annex describes the. technical differences between the protocol for Reliable Transfer of this part of ISO/IEC 9066 and the corresponding protocol of CCITT Recommendation X.4IO - 1984. In X.410-1984 mode this part of ISO/IEC 9066 and its use of ACSE and Presentation service is bit compatible to CCITT Recommendation X.410 1984 under consideration of the clarifications and errata of the X.400 - Series Implementors Guide V. 5. B.1.3 Ptiefuse

The SET type is now Presentation protocol control information. The elements of the RTORJapdu are the elements of the PRefuse SET. Implicit tagging of the SET in normal mode. Additional mode. B.l.4 optional user data field in normal

DataTransferSyntax protocol

B.1
B.l.l

Application Units
PConnect

Protocol

Data

This information is now Presentation control information. B.1.5 Abortlnformation

The Set type and its two elements (Data Transfer Syntax and pUserData) are now Presentation protocol control information (PPCI). The Elements of the RTORQapdu are the elements of the SET pUserData. The application Protocol element is now OPTIONAL and solely used in X.410-1984 mode. implicit tagging of the SET in normal mode. B.1.2 PAccept

The SET type is now Presentation protocol control information. The elements of the RTABapdu are the elements of the AbortInformation SET. Implicit tagging of the SET in normal mode. Additional mode. B.1.6 Add: optional user data field in normal

Abort Reason Values (51 to (61 inclusive. Value (71 was added by the Addendum of the X.400 Series Implementors Guide Version 5.

The SET type and its two elements (DataTransferSyntax and pUserDdta1 are now Presentation protocol control information. The elements of the RTOACapdu `are the elements of the SET pUserData. Implicit tagging of the SET in normal mode.

B.2
Change:

Procedures and Mapping
From: Mapping onto Session Services To: Mapping onto AME and Presentation services.

General Mapping onto used services.
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Annex C
(informative)

Summary of assigned object identifier values.

This annex summarizes
fioint-iso-ccitt fioint-iso-ccitt reliable-transfer reliable-transfer

the object identifier values assigned in ISO/IEC 9066-l
(3) apdus (0)) (3) areID (1)) --_

and ISO/IEC 9066-2.

ASN.1 module RTSE identifier

defined in KSOilEC 9066-2

-_
( joint-iso-ccitt reliable-transfer
(3) abstract-syntax (2) ) --

defined in ISO!KEC 9066-2 Abstract syntax name defined in 1SOIlEC 9066-2

-_
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